I have a little issue with SonarQube to scan PHP code.
When scanning the work, there is an error coming a hundred times:
Move this open curly brace to the end of the previous line
This apply on this code for example:
class Edit extends Container
{
It shouldn't as PSR are clear on this topic :
Opening braces for classes MUST go on the next line, and closing
braces MUST go on the next line after the body.
Opening braces for
methods MUST go on the next line, and closing braces MUST go on the
next line after the body.
Opening braces for control structures MUST
go on the same line, and closing braces MUST go on the next line after
the body
When I look in the detail of the error in Sonar, this is what the rule seems to follow, which is not appropriate:
Sharing some coding conventions is a key point to make it possible for a team to efficiently collaborate. This rule make it mandatory to place open curly braces at the end of lines of code.
And there it shows me the example of the if condition
if(...) {
//...
}
Any idea to follow the proper rule?
Finally I found a solution:
edit your project configuration by disabling the faulty rules and enabling the wanted ones, in this case: PSR2. You can also add some additionnal rules, for example in my case, the Magento 2 ones ;
to make the changes taken in to account: launch a new build.
Hope it will help other.
Related
I have a weird bug. When I beautify my html/php mixed code it breaks the line and puts the echo and the following tag on 2 different lines making it look ugly.
Anyone had this problem before ?
BTW look at $answer_hash['topic_firstname'] suddenly the following )) are green/commented looks like.
Not sure, my only guess would be that you have softwrap (also called wordwrap) on. You can disabled it at: View -> Toggle softwrap.
To awnser your second question, the value="" attribute normal contains string, and not code. So it gets the green color as if it is a string.
You're using the standard syntax theme that doesn't give a color to parentesis and curly braces, so since it's in a value="" attribute it gets the green color.
It's default behavior of PHP-CS-Fixer (I assume you use the default PHP beautifier of atom-beautify in version 2) to break lines after curly braces.
The body of each structure MUST be enclosed by braces. Braces should
be properly placed. Body of braces should be properly indented.
Scroll down to 'braces [#PSR2, #Symfony]'
Which is defined in the PSR-2 coding style guide:
Opening braces for control structures MUST go on the same line, and closing
braces MUST go on the next line after the body.
If you switch back to version 1 in the atom-beautify settings it won't do the line breaks but it stop fixing other things only available in version 2.
For completeness (although rpm192) has already answered the second part of your question: The )) are green because the standard color for html attribute values is green. Since your document type is set to PHP, all built in functions, arrays etc. between PHP-tags are colored differently but everything else, which does not have a different color specified, keeps it's previous color (which in this case is green). As you can see in the screenshot if you place the PHP-code outside of the html attribute value the braces are colored white as usual.
Note: You have more opening curly braces { than closing ones. Check out line 6 in my screenshot.
I'm looking for a rule that prevents empty lines after the opening brace of a class.
I found the rule Squiz.WhiteSpace.FunctionOpeningBraceSpace for functions, but I can't find any for classes.
Any suggestions are appreciated.
You are looking for no_blank_lines_after_class_opening from FriendsOfPHP/PHP-CS-Fixer.
If you want to use CodeSniffer, you still can. With EasyCodingStandard you can use both.
# easy-coding-standard.neon
checkers:
- PhpCsFixer\Fixer\ClassNotation\NoBlankLinesAfterClassOpeningFixer
Do you want more? Check this short post.
Should there be a space between <?php and namespace inside a php class file?
I am looking for this information in PSR guidelines. There are indication about a space after. But before?
PSR-2-coding-style-guid
PSR-2 Its purpose is to have a single style guide for PHP code that results in uniformly formatted shared code.
Code MUST use 4 spaces for indenting, not tabs.
There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of usedeclarations
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be
declared after the visibility
Control structure keywords MUST have one space after them; method and function calls MUST NOT.
Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT
have a space before.
Basic Coding Standard [PSR-2]
*Files
All PHP files MUST use the Unix LF (linefeed) line ending.
All PHP files MUST end with a single blank line.
The closing ?> tag MUST be omitted from files containing only PHP.
Lines
There MUST NOT be a hard limit on line length.
The soft limit on line length MUST be 120 characters; automated style checkers MUST warn but MUST NOT error at the soft limit.
Lines SHOULD NOT be longer than 80 characters; lines longer than that SHOULD be split into multiple subsequent lines of no more than
80 characters each.
There MUST NOT be trailing whitespace at the end of non-blank lines.
Blank lines MAY be added to improve readability and to indicate related blocks of code.
There MUST NOT be more than one statement per line.
Indenting
Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
Keywords and True/False/Null
PHP keywords MUST be in lower case. ( e.g. echo , die, for, throw, catch )
The PHP constants true, false, and null MUST be in lower case
NameSpace and Use Declaration
When present, there MUST be one blank line after the namespace declaration.
When present, all use declarations MUST go after the namespace declaration.
There MUST be one use keyword per declaration.
There MUST be one blank line after the use block.
I am editing some code that I've inherited from elsewhere and there seems to be a problem with the script tags in this section of the code. If I remove them the page runs but obviously the javascript does not run.
I'm not too good with php so I'm not sure how to fix this.
$GLOBALS['TEMPLATE']['extra_head'] = <<<ENDHTML
<script src='js/ajax.js' type='text/javascript'></script>
<script src='js/blog.js' type='text/javascript'></script>
ENDHTML;
Just a guess, but if there are any characters (including spaces or tabs) on the same line before or after the closing delimiter of the HEREDOC, you will get errors.
From the manual:
Warning
It is very important to note that the line with the closing identifier must contain no other characters, except possibly a semicolon (;). That means especially that the identifier may not be indented, and there may not be any spaces or tabs before or after the semicolon. It's also important to realize that the first character before the closing identifier must be a newline as defined by the local operating system. This is \n on UNIX systems, including Mac OS X. The closing delimiter (possibly followed by a semicolon) must also be followed by a newline.
If this rule is broken and the closing identifier is not "clean", it will not be considered a closing identifier, and PHP will continue looking for one. If a proper closing identifier is not found before the end of the current file, a parse error will result at the last line.
What you eluded to (blank screen and broken syntax highlighting in your text editor) would be the result or symptom of a parse error if error reporting is off. It's hard to see if this is the case in your post, being outside the context of the actual file.
Check that out and see if it is applicable.
Aside: It's a good habit to turn on error_reporting(E_ALL) while in development.
Those 'tags' just allow you to enter bare HTML within PHP code without having to use quotations etc.
It's assigning anything between those 2 tags to the variable: $GLOBALS['TEMPLATE']['extra_head']
Example:
<?php $formElement->display()?>
Is this fine, or should I provide a ; ?
Well I guess that the PHP interpreter is clever enough to see that the line is finished and the expression done because of the ?> at the end. Right?
It is not required, but you should put it, as a good practice.
That way, the day you need to add another instruction after this one, it'll work fine.
And here is the manual's page that answers your question : Instruction separation (quoting, emphasis mine) :
As in C or Perl, PHP requires instructions to be terminated with a semicolon at the end of each statement.
The closing tag of a block of PHP code automatically implies a semicolon; you do not need to have a semicolon terminating the last line of a PHP block.
The closing tag for the block will include the immediately trailing newline if one is present.
No, the closing ?> will automatically close the line.
From the PHP Docs:
The closing tag of a block of PHP code automatically implies a semicolon; you do not need to have a semicolon terminating the last line of a PHP block.
As you say, the PHP interpreter will cope as-is.
However, I'd say that adding the semicolon is probably slightly better practice, but that's just a personal coding preference.
Simple answer: yes. It's okay to only have one statement without a semicolon inside PHP tags.