Generic.Formatting.MultipleStatementAlignment wrong error for assign in string concat

[sertand]

If you have:

$i = 0;
echo "TEST: ".($i += 1)."\n";

You get this error:

Equals sign not aligned with surrounding assignments; expected 17 spaces but found 1 space (Generic.Formatting.MultipleStatementAlignment.NotSame)

Expected to be no errors

[jrfnl]

@sertand Got another false positive for you if you're working on that sniff anyway:

$phrase = 'phrase';
if ($a === true)
    if ($b === true)
        $phrase = 'another phrase';
else
    $phrase = 'different phrase';

[gsherwood]

I've fixed this specific issue, so am going to close.

Got another false positive for you if you're working on that sniff anyway:

This is not a sniff issue. The tokenizer is not assigning any of the assignment operations to the IF or ELSE statements due to the lack of braces. There is nothing the sniff can do to detect this and it would impact other sniffs as well. I have no idea how to fix it, so it would be good to open a new issue for this one.

[jrfnl]

This is not a sniff issue. The tokenizer is not assigning any of the assignment operations to the IF or ELSE statements due to the lack of braces. There is nothing the sniff can do to detect this and it would impact other sniffs as well. I have no idea how to fix it, so it would be good to open a new issue for this one.

Will do.

I was actually thinking along the lines of a check that if the next assignment is not on the next line, the assignment block has ended. Could that work in your opinion ?

[gsherwood]

I was actually thinking along the lines of a check that if the next assignment is not on the next line, the assignment block has ended. Could that work in your opinion ?

You've got me thinking now. I don't know why it doesn't already do that - I thought that's how it worked. The sniff is a mess and hard to read, but I don't have time to rewrite it, so I'll just keep digging and see if it is supposed to do this. Thanks.

[gsherwood]

I don't know why it doesn't already do that

I know why. It only considers a blank line the end of the code block. This is so it doesnt get confused if some of the assignments are multi-line, like in the case of closures.

It might be possible to rewrite this check so it skips to the end of the statement and continues checking from there, but I'm worried it would still be tripped up by the code sample above. I think it's best to try and fix the tokenizer itself, although a lot harder.