PHP Zend Framework coding standard, which is a more readable approach?

This is a subjective question, I need your feelings and thoughts about coding standards and formatting methods.

The PHP Zend encoding standard requires multi-line function calls to be written as follows:

$returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); 

I think the following approach is more readable:

 $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); 

If you see only one line on the left side, this means that it is only one operator, and the arguments are closer to the method name.

Which one prefers YOU ?

+7
coding-style php zend-framework
source share
7 answers

The second approach gives you one additional problem: line length. The Zend coding standard assumes that "the maximum length of any line of PHP code is 120 characters."

This means that if you want to have good (long, descriptive) variable names and you have one for the return value, an object, a good named function, and a long parameter, you are likely to reach the limit of 120 characters.

Add to this, and depending on your standard, the maximum length can be as little as 80 characters or something in between.

Also, I like the first one better if you reuse it

 $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); 

As Pekka said, fewer eyes jump.

+14
source share

I like the first approach better. The latter requires more typing and more annoying IMO. I think that the eye - for the "western", at least the left side of the right side of humanity - seeks to go to the beginning of the next line when it arrives at the end of the current line, and to jump too much free space in the second example. It may not be semantically 100% correct, but it provides a good read stream.

+10
source share

I like the PEAR standard and it protects the first of your examples

 $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); 

but I could do this for such a short set of parameters:

 $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); 

EDIT: Oh! and for sidereal example:

 $notInlined = longInlinedMethod($argFoo, $argBar) + otherLongInlinedMethod(); $returnedValue = $object->longMethodName( $arg1, $notInlined, $arg3, $arg4 ); while ($val) { someStatement(); } 
+3
source share

Of the two provided by you, I prefer the first.

If there is a coding standard, I will follow it. However, not at my work, and I prefer the following:

 $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); 

It’s easier for me to immediately see that the variable is being set (due to the fact that the parameters and the closing bracket are indented. In the Zend standard, you should actually look for the equal sign to see that it is the destination, otherwise it could be confused with a simple multi-line call functions.

One more comment ... my function calls only become multi-line if they exceed 120 characters. In my IDE with a resolution of 1600x1200, no more than 120 characters will not be displayed if they are not displayed in the Workspace browser and in the Code Navigator navigation bar.

This line of code has only 74 characters, so I would do the following:

 class myClass { public function myFunction(...) { $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); } } 
+2
source share

None? Option A is potentially confusing because one block is used for code blocks. Option B is problematic with long argument names and / or deep indentation.

I prefer double indentation to continue argument lists.

Example for erenon:

 $returnedValue = $object->longMethodName( $arg1, longInlinedMethod($argFoo, $argBar) + otherLongInlinedMethod(), $arg2, $arg3); while ($val) { someStatement(); } 
+1
source share

I usually use First, but with a closing bracket on the same line or at least with the same indentation as above.

 $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42 ); $returnedValue = $object->longMethodName( $argument1, $otherArgument, 42); 

This seems to avoid level confusion when nesting for me.

However: my indent in vim started doing the same thing as in Paren (2, above), and I like it. I break it down on long lines that need wrapping help, but overall I think this leads to a readable code if you are first looking at method names instead of parameters.

BTW, doing this indentation for nested Boolean operators, also works well.

I will also group the arguments on one line if they are not too long, and they make sense to group.

+1
source share

I prefer the first for two reasons:

  • This allows you to use the Tab key for indentation (or keyboard shortcuts for indentation / unindent) without worrying about adding extra spaces so that your arguments line up.
  • More importantly, you do not need to indent the argument if the length of the name of the variable, object or method changes in the first line.
+1
source share

All Articles