For configuration or updating questions please read the README and UPGRADE documentation,
or visit: https://gitter.im/PHP-CS-Fixer
When reporting an issue (bug) please provide the following information:
$ php -v):=> 7.2.6
$ php-cs-fixer -V):=> 2.12.2
=>
'@Symfony' => true,
'binary_operator_spaces' => array(
'align_double_arrow' => true
),
'concat_space' => false,
'full_opening_tag' => false,
'no_closing_tag' => false,
'no_trailing_whitespace_in_comment' => false,
'phpdoc_var_without_name' => false,
'semicolon_after_instruction' => false,
'trailing_comma_in_multiline_array' => false,
'yoda_style' => false,
'function_declaration' => false,
'single_quote' => false,
'elseif' => false
if ($check == 0) {
$test = 0;
} else if ($check == 1) {
$test = 1;
} else if ($check == 2) {
$test = 2;
} else if ($check == 3) {
$test = 3;
} else if ($check == 4) {
$test = 4;
}
if ($check == 0) {
$test = 0;
} else {
if ($check == 1) {
$test = 1;
} else {
if ($check == 2) {
$test = 2;
} else {
if ($check == 3) {
$test = 3;
} else {
if ($check == 4) {
$test = 4;
}
}
}
}
}
if ($check == 0) {
$test = 0;
} else if ($check == 1) {
$test = 1;
} else if ($check == 2) {
$test = 2;
} else if ($check == 3) {
$test = 3;
} else if ($check == 4) {
$test = 4;
}
The problem happens when I use else if in separate words compared to one word.
The braces fixer in the fixMissingControlBraces method breaks up the else-if statement.
See #3535
But why is "else if " not registered as an T_ELSE_IF, since it is similar in appropriate usage ?
Why would it? We are not over-interpreting tokes because they are "similar" - else if are 3 tokens and that is how they should be parsed.
If you claim they are similar why don't you want them to be the same? Why having 'elseif' => false configuration, which is violation of PSR2?
Hm..good point about the PSR2 standard actually enforcing the usage of "elseif" over "else if".
In that regard it doesnt make too much sense, I agree.
Of course only using the braces fixer without the elseif fixer will still provide these problems, but at least I can now see how to proceed with this specific case.
https://www.php-fig.org/psr/psr-2/#51-if-elseif-else
The keyword elseif SHOULD be used instead of else if so that all control
keywords look like single words.
I think the fixer act as it should here
I'm closing for now as I don't see a big community using this style and PSR2 gives clear directions.
As always, feel free to discuss more here, I'm closing here to make it more easy for maintainers.
Of course only using the braces fixer without the elseif fixer will still provide these problems
PHP CS Fixer is not meant to run rules one by one. It can execute, but the real power is in running desired ruleset as a whole.
using elseif + braces together gives more than using them separately, and that is for most of the rules we are providing.
I wanted to do the same, but did not want to invest much so I ended up with a little hack in the config
->registerCustomFixers([new class extends \PhpCsFixer\AbstractFixer
{
public function getDefinition()
{
return new FixerDefinition(
'The keywords `else if` should be used instead of `elseif`.',
[new CodeSample("<?php\nif (\$a) {\n} elseif (\$b) {\n}\n")]
);
}
public function getName() { return 'Custom/no_elseif'; }
public function getPriority() { return -30; }
public function isCandidate(\PhpCsFixer\Tokenizer\Tokens $tokens)
{
return $tokens->isAllTokenKindsFound([T_ELSEIF]);
}
protected function applyFix(\SplFileInfo $file, \PhpCsFixer\Tokenizer\Tokens $tokens)
{
foreach ($tokens as $index => $token) {
if (!$token->isGivenKind(T_ELSEIF)) {
continue;
}
$tokens[$index] = new \PhpCsFixer\Tokenizer\Token([T_ELSE, 'else']);
$tokens->insertAt($index+1, new \PhpCsFixer\Tokenizer\Token([T_WHITESPACE, ' ']));
$tokens->insertAt($index+2, new \PhpCsFixer\Tokenizer\Token([T_IF, 'if']));
}
}
}])
->setRules([
// other rules here, must include elseif
'Custom/no_elseif'])
I'm closing for now as I don't see a big community using this style and PSR2 gives clear directions.
As always, feel free to discuss more here, I'm closing here to make it more easy for maintainers.
PSR2 gives SUGGESTIONS, not REQUIREMENTS. It clearly says should, not must. Plenty of people use custom rules that differ from PSR2; every workplace I've worked at has had some differences, sometimes minor, sometimes major, and split else if is a common one. Having a tool such as this enforcing any custom style would be awesome, but you don't support a simple style change such as this, and that is embarassing.
@kubawerlos screw you! This software should be agnostic and allow for any configuration! It could be so much greater if it would.
@jurchiks this is not personal, so please refrain from making this kind of remarks, they are not welcome here
@jurchiks this software is nothing more than the result of contributions from people who do it for free, in their spare time - the contributions made with the belief of their authors.
If you cannot understand this and respect this I feel sorry for you.
You believe your change is good and would make PHP CS Fixer even better, so implementing it and merging via pull request is the way to go.
That's understandable, but the way you just go and disregard a completely normal feature suggestion is not.
@SpacePossum the reason I said that was because of his downvote on my first comment. That was personal.
Most helpful comment
@jurchiks this software is nothing more than the result of contributions from people who do it for free, in their spare time - the contributions made with the belief of their authors.
If you cannot understand this and respect this I feel sorry for you.
You believe your change is good and would make PHP CS Fixer even better, so implementing it and merging via pull request is the way to go.