You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
make a list of all the coding style conventions the different PHP factions
tend to squabble or complain about
Add code examples explaining the different possible variations
Solicit feedback from a few more renowned (or opinionated) community members
with the aid of semaphores, tin-can-phone or smoke signals. Or twitter if my
wife still won't let me play with matches.
Edit the text to reflect various contributions
...
Profit!
[UPDATE]:
After creating a list based on the PSR2 I began to get this feeling of
uncertainty that it might be incomplete. It was also unclear from the PSR2 alone
where conflicts would arise with other conventions. So rather than to just guess
and hope for the best I decided to take several coding standards and map their
conventions and that way I would have an actual basis in fact for my set of
possible convention conflicts. I got a bit too obsessed with the detail for a
while there, causing some delay. Various yaks needed shaving an I
changed jobs during that period as well, but I got my act together in the end.
Step 1 - Compose as list
The best place to go to find out which coding style clashes we as a community
have seemed to me to be the FIG site. Based on the PSR-1 and PSR-2 I came up
with the list below.
Step 2 - Add examples
Several weekendends later, my list sort of turned into a side project in
it's own right but putting it all back together and drawing it back into the
scope of this project, it looks complete.
The following list contains all of the conventions I can think of to include in
the convention list. It is based on a comparison of various conventions as
dictated by various more well-know projects.
Some of these may be dropped under influence of comments or lack of good
examples.
Space (Control Structure Brackets/Around Param Block/Method Declaration Inside Param Block)
Naming Convention
Class Names
Class Constant Names
Class Method Names
Class Variable Names
Constant Names
Function Names
Namespace Usage
PHP Constants Casing
PHP Keyword Casing
Other
Method Declare Order
Dockblocks
Closing Tags
Short Tags (general/echo)
Always use Control braces
Castaways and Cutouts
There are several things mentioned that I don't think fall under "code style
clash" but rather good/bad practices. I don't think these need to be included.
Also, various things might be too tricky to measure and should be left out
because of that.
Class name prefixes and suffixes :
In lue of using proper namespace features (older) code often falls back to
using snake case and prefixes for vendors, etc. I think this will be
reflected in the naming convention checks and doesn't warrent this level of
detail.
Comments and documentation blocks :
Various styles could be easy to check, like //, # and /**/. However,
there would have to be a check to take docblocks into account /** */,
otherwise that would throw everyting of in favour of /**/.
Conventions for file names :
There are various conventions on how to name a file depending on whether it
contains a class, config or other forms of content but I don't think this
could be reliably measured.
Declaration of global variables and global constants :
Doesn't seem worth the effort to gauge this.
Declaration of Functions :
Check whether people only declare functions as class methods or as procedural
functions. Do we care? I think this is more context dependant than coding or
convention style.
Error Level :
This one is alsorather ambiguous as often the error level is declared outside
of the project code. There could be a check for usage of error_reporting
but then integers could be used instead of constants, making the whole thing
more tiresome than seems worth the effort.
Operators and assignment (Yoda Conditions/Left Side Comparison) :
This would be hard to reliably check for without doing extra code analysis
(scan for the dollar sign $). Could be worthwhile to find out. Not sure.
Inter-line alignment (Vertical Lining Up Values) :
Why bother? People hardly seem to notice the difference as is.
Line Length (hard limit/soft Limit) :
I have a feeling this would rather hard to check for, since normative lines
of code will be less than 80 characters long anyway.
Usage of include_once versus require_once? :
Doesn't seem worth the effort and can very likely be context dependant.
Usage of underscore '_' for private/protected properties :
This is a bit of PHP4 legacy. The PSR explicitly says "do not use", some
others explicitly say yes. Could be interesting. Not sure.
class Foo
{
public static function bar($baz)
{
// ...
}
}
static declared before visibility
class Foo
{
static public function bar($baz)
{
// ...
}
}
abstract (or final) declared after visibility
class Foo
{
public abstract function bar($baz);
// ...
}
abstract (or final) declared before visibility
class Foo
{
abstract public function bar($baz);
// ...
}
Dockblocks
Docblocks manditory
/**
* The Foo Class
*
* Takes care of all of the foos
*/
class Foo {
/**
* Bar a given Baz
*
* @param $baz
*
* @return bool
*/
function bar($baz) {
// ...
}
}
Docblocks optional
class Foo {
function bar($baz) {
// ...
}
}
Closing Tags
Closing tag ?> allowed or manditory
<?php
// ...
?>
Closing tag ?> not allowed
<?php
// ...
#EOF
Short Tags (general)
Short tag '<?' allowed
<p>
<? echo $baz ?>
</p>
Short tag '<?' not allowed
<p>
<?php echo $baz ?>
</p>
Short Tags (echo)
Short echo tag '<?=' allowed
<p>
<?= $baz ?>
<p>
Short echo tag '<?=' not allowed
<p>
<? echo $baz ?>
</p>
Always use control braces
Control braces mandatory
if($baz) {
// ..
} else {
// ..
}
Control braces optional
if($baz)
// ..
else
// ..
Castaways and Cutouts
Linelength
Limit on 80 characters
// Break before hitting the 80 character line
//----------------------------------40-↓----------------------------------[80]-↓-----------------------------------120-↓-----------------------------------160-↓-----------------------------------200-↓-----------------------------------[∞]-→
$iterator = new RecursiveDirectoryIterator(
$folder, FilesystemIterator::CURRENT_AS_FILEINFO
| FilesystemIterator::KEY_AS_PATHNAME
| FilesystemIterator::FOLLOW_SYMLINKS | FilesystemIterator::SKIP_DOTS
| FilesystemIterator::UNIX_PATHS
);
Limit on 100 characters
// Break before hitting the 100 character line
//----------------------------------40-↓------------------------------------80-↓-------------[100]-↓---------------120-↓-----------------------------------160-↓-----------------------------------200-↓-----------------------------------[∞]-→
$iterator = new RecursiveDirectoryIterator(
$folder, FilesystemIterator::CURRENT_AS_FILEINFO | FilesystemIterator::KEY_AS_PATHNAME
| FilesystemIterator::FOLLOW_SYMLINKS | FilesystemIterator::SKIP_DOTS
| FilesystemIterator::UNIX_PATHS
);
Limit on 120 characters
// Break before hitting the 120 character line
//----------------------------------40-↓------------------------------------80-↓---------------------------------[120]-↓-----------------------------------160-↓-----------------------------------200-↓-----------------------------------[∞]-→
$iterator = new RecursiveDirectoryIterator(
$folder, FilesystemIterator::CURRENT_AS_FILEINFO | FilesystemIterator::KEY_AS_PATHNAME
| FilesystemIterator::FOLLOW_SYMLINKS | FilesystemIterator::SKIP_DOTS | FilesystemIterator::UNIX_PATHS
);
No limit on line length
// I Break for no-one!
//----------------------------------40-↓------------------------------------80-↓-----------------------------------120-↓-----------------------------------160-↓-----------------------------------200-↓-----------------------------------[∞]-→
$iterator = new RecursiveDirectoryIterator($folder, FilesystemIterator::CURRENT_AS_FILEINFO | FilesystemIterator::KEY_AS_PATHNAME | FilesystemIterator::FOLLOW_SYMLINKS | FilesystemIterator::SKIP_DOTS | FilesystemIterator::UNIX_PATHS);
Operators and assignment (Yoda Conditions/Left Side Comparison)
Normal comparison
if($baz === 'baz'){
// ...
}
Yoda Condition/Left Side Comparison
if('baz' === $baz){
// ...
}
Inter-line alignment (Vertical Lining Up Values)
Non-Aligned Values
$baz = 'baz';
$quux = 'qux';
$foozle = 'foo';
Aligned Values
$baz = 'baz';
$quux = 'qux';
$foozle = 'foo';
Comments and documentation blocks
Perl Style Comments
# This is a comment
C++ Style Comments
// This is a comment
C Style Comments
/* This is a comment */
Usage of underscore '_' for private/protected properties
Does not use underscore '_' for private/protected properties
class Foo {
protected function bar($baz) {
// ...
}
}
Uses underscore '_' for private/protected properties
class Foo {
protected function _bar($baz) {
// ...
}
}
pretty many convention.. :D @Potherca There are something you have to understand.
In my project, some limitation is exist. It analyze convention line by line.
So, It could check space or tab, but not 2 spaces or 4 spaces.
and it can check if, else statements each but not if and else statement together.
I will fix some convention to fit my project.
pretty many convention.. :D
@Potherca There are something you have to understand.
In my project, some limitation is exist. It analyze convention line by line.
So, It could check space or tab, but not 2 spaces or 4 spaces.
and it can check
if
,else
statements each but notif
andelse
statement together.I will fix some convention to fit my project.