Spacing in function calls

[jhsachs]

I'm writing coding standards for my organization, and I'm facing an issue of when to use spaces that has long troubled me. This may seem trivial, but within the topic of standards, the trivial becomes important.

 

Virtually every programming standard I've ever seen allows no spaces between the first or last parameter in a function call and the adjacent parenthesis:

 

function($parm1, $parm2, $parm3);

 

I've never seen a reason given for this. On the other hand, there are substantial reasons why it is bad practice.

 

First, it implies that the first parameter is more closely associated with the function name than with the other parameters, which is absurd.

 

Second, the close parenthesis tends to merge visually with the last parameter, making it easy to misjudge where the parameter list ends in a complex expression.

 

Third, if the last parameter is complex enough to require parentheses, it makes the code much more difficult to understand:

 

function($parm1, $parm2, round(($upper+$lower)/2+0.5));

 

My own rule is that if the parameter list is complex enough to benefit from spaces, spaces should be inserted between parameters, before the first, and after the last:

 

function(parm1,parm2,parm3);
function( $parm1, $parm2, round(($upper+$lower)/2+0.5) );

 

I'd like to hear others' comments on this before I decide whether to tell my organization to do what the rest of the world does, or try to make it do something totally nonstandard that (in my judgment) yields better code.

[.josh]

Although I see different spacing conventions all over the place for this...I've never really heard people argue over this spacing, and TBH IMO people will probably think you are being a bit anal for asking to adhere to a standard that granular.  As far as formatting, IMO the only things you should try to standardize are

 

a) comments

b) indention

c) bracket placement

 

Having said that, if you for whatever reason absolutely must write and enforce standards for something you rightfully call trivial, here are my 2 cents:

 

First, it implies that the first parameter is more closely associated with the function name than with the other parameters, which is absurd.

 

I don't think this is absurd, I think it is true.  When I create a function, I generally try to order the arguments by importance and/or whether or not they are optional.  So by that convention, the first argument is more associated with the function (in purpose, but also in name, since you usually name your function something having to do with its purpose, and arguments passed are also named in such fashion). 

 

But note that I'm only mentioning a counter-argument because you brought it up;  I personally think that while naming conventions and argument positions make for more readable code, you're arguing about spacing here, which is kind of a different argument...

 

Second, the close parenthesis tends to merge visually with the last parameter, making it easy to misjudge where the parameter list ends in a complex expression.

 

Third, if the last parameter is complex enough to require parentheses, it makes the code much more difficult to understand

 

 

IMO I will sometimes agree with this.  TBH my spacing changes, depending on the actual code.  If it is a single line like in your example, I might be inclined to put a space between the parens like that.  But if it is part of a larger bit of code, IMO the more readable thing would be to not space it, and put a space between the closing bracket and next bit of code.

 

But anyways, the problem is that it boils down to personal opinion.  Different people have different ideas of what is more readable.  Also, let's not get confused here... spacing does not produce "better code".  PHP (and most other parsers/compilers) for the most part does not give a damn about it.  It *might* lead to more efficient programming / time management because it *might* make it more readable, easier for new coders to come in and get up to speed or whatever, but that is not the same as "better code".  Anyways...

 

So again, my first advice to you is to not nickel and dime this, stick to the bigger things. 

 

Failing that, my next advice would be...sure, you could get all philosophical about how progress doesn't happen without going against the grain or something, but do you really get paid enough to set and fight for new "worldwide" standards...in some random organization?  Think about that for a minute, and the choice should be obvious:  go with what the "rest of the world" does.  From the other coders the only feedback you will get is more or less what I'm telling you now: it's a matter of opinion and trivial.  From non-coders you will have to defend why it is you somehow think your opinion outweighs the rest of the world, and in my experience, all they hear is "blahblahblah" because they aren't coders. 

 

 

 

[Philip]

According to the ZF Coding Standards, no... no spaces. Personally, I have to agree with it.

 

If you have something as complex as

<?php
function($parm1, $parm2, round(($upper+$lower)/2+0.5));

I'd be setting that as a var before passing it into a function call - but thats just me.

[scootstah]

Second, the close parenthesis tends to merge visually with the last parameter, making it easy to misjudge where the parameter list ends in a complex expression.

 

Third, if the last parameter is complex enough to require parentheses, it makes the code much more difficult to understand:

 

function($parm1, $parm2, round(($upper+$lower)/2+0.5));

 

What do you develop with, Notepad? Any modern IDE/editor has syntax highlighting (and bracket matching), so I don't see why this would ever be a problem.

[.josh]

If you have something as complex as

<?php
function($parm1, $parm2, round(($upper+$lower)/2+0.5));

I'd be setting that as a var before passing it into a function call - but thats just me.

 

That too.  If your ultimate goal here is to make code more readable...you wouldn't be trying to shove everything into one line like that in the first place. 

[The Little Guy]

myFunc($p1, $p2, $p3){
$p1 = (bool)call_user_func($p1);
if($p1)
	retrun "Smoosh Smoosh";
if($p2 == "cat")
	return "Meow!";
else
	return "Error";
}

echo myFunc(function(){
$num = $_POST['number'];
for($i=$num;$i > 0;$i--){ 
	$v = $num / $i; 
	if(!is_float($v)){ 
		if($v != $num && $v != 1) 
			return false; 
	} 
} 
return true; 
}, ("cat"==$animal?("red"==$color?(12=="age"?("mamal"==$type?"cat":false):"dragon"):"monkey bars"):false), preg_replace("/[0-9]/", "123", round(($upper+$lower)/2+0.5)));

 

nuf said!

[jhsachs]

Thanks for the varying perspectives. I'm going to respond to just a few of the comments.

 

KIS is a good principle, one which I try to adhere to (and which my boss often tells me to consider after I think I've pushed it as far as I can). In this case, however, I'm developing my standard largely by taking ideas from several established standards: PEAR Coding Standards, CodeIgniter General Style and Syntax, and Drupal Comment Formatting Conventions. Most of my work has consisted of cutting. My document is shorter than any of my sources, despite the fact that I'm borrowing concepts from all three.

 

So, how simple should simple be? Judging by the standards I started with, I think I've done a darned good job. The document is still longer than I'd like (13 pages, or 8 pages without the examples and front matter), but it's not clear what can be cut without real loss.

 

Evidently I put more emphasis on the role of spacing in legibility than many other programmers do. I don't think it would be useful to debate who's "right" and "wrong"; I'll just observe that I developed my own practices over decades by observing my experience with my own code and others'. No one is going to convince me that spacing isn't important to me. I've had too much experience having to reformat other programmer's code before I could make sense of it to believe that.

 

Finally, I just don't know what to make of the comment that spacing doesn't matter because "Any modern IDE/editor has syntax highlighting (and bracket matching)..." There's a huge difference between being able to understand what a piece of code does by looking at it, and finding that that bracket in this statement matches this one because the the editor highlights one when I put the cursor on the other. It's the difference between looking at a room through a door and looking at it through a keyhole.

[.josh]

So, how simple should simple be? Judging by the standards I started with, I think I've done a darned good job. The document is still longer than I'd like (13 pages, or 8 pages without the examples and front matter), but it's not clear what can be cut without real loss.

 

Well for starters, you can cut out this bit about spacing.  As it has already been stated, it boils down to a matter of opinion, and you even go on to acknowledge:

 

Evidently I put more emphasis on the role of spacing in legibility than many other programmers do. I don't think it would be useful to debate who's "right" and "wrong"; I'll just observe that I developed my own practices over decades by observing my experience with my own code and others'. No one is going to convince me that spacing isn't important to me.

 

Notice the theme here?  Your spacing conventions are your opinion.  Everybody has their own opinion on what is more readable.  Sorry, but IMO it sounds like you aren't trying to make a standard that helps everybody, you're trying to make a standard that helps you.

 

I've had too much experience having to reformat other programmer's code before I could make sense of it to believe that.

 

Sorry, but I'm calling b.s. on this.  You say you've had decades of experience in coding.  Now I don't disagree that you've probably had to first go reformat some of the bigger things like someone putting 100 things on one line, or lack of indentions, etc.. but if after decades of experience coding you can't make heads or tails out of code unless there's a space between some commas or parens in a given expression... IMO that doesn't add up. 

 

That's like saying you're an editor of a publishing firm a teacher at a school..been reviewing/grading writings for many years, yet having to reformat submitted books or turned in written assignments before being able to figure out wtf is written.  That just doesn't happen.  With experience, you know what you're reading about, even if the grammar/syntax  is "improper".  That's the difference experience makes. 

 

Soo...either you don't have the experience you claim to have, or if you have been doing it for that long, maybe you aren't the person should be writing standards.  Just sayin'...

 

Finally, I just don't know what to make of the comment that spacing doesn't matter because "Any modern IDE/editor has syntax highlighting (and bracket matching)..." There's a huge difference between being able to understand what a piece of code does by looking at it, and finding that that bracket in this statement matches this one because the the editor highlights one when I put the cursor on the other. It's the difference between looking at a room through a door and looking at it through a keyhole.

 

Have you actually tried using a modern IDE with syntax highlighting, bracket matching, etc..? You can understand the code more easily because of these features.  The whole point you're trying to make as far as spacing is being able to quickly scan for breakpoints etc.. so that you can get that out of the way and start understanding what the code is actually doing.  I don't know about you, but when an editor automatically highlights that breakpoint for me...that's a lot more visual than scanning for a blank space - especially when you're also having to mentally filter out the non-relevant spaces when scanning it "traditionally."

 

I think overall you're missing the point, and again, no offense but TBH I think it's because (IMO) you aren't really looking at it from a "what makes things easier for everybody" perspective, but what's easier for you.  Nobody is arguing that these "standards" of yours is easier for you.  We're simply arguing that different "standards" are easier for different people, and you should not try to standardize something this granular.

 

As previously stated, I advise you stick with the bigger formatting "issues" such as commenting, bracket placement and indentions, but if you are somehow required to be specific about even spacing...there is no debate about what you should use: go with what has already been established as the "standard", not what you personally think is best.  Again, not saying you are wrong for having your own idea of what's easier to read.  I'm just sayin' you're wrong for making this about you. 

[scootstah]

Finally, I just don't know what to make of the comment that spacing doesn't matter because "Any modern IDE/editor has syntax highlighting (and bracket matching)..." There's a huge difference between being able to understand what a piece of code does by looking at it, and finding that that bracket in this statement matches this one because the the editor highlights one when I put the cursor on the other. It's the difference between looking at a room through a door and looking at it through a keyhole.

 

So you think

function( $parm1, $parm2, round(($upper+$lower)/2+0.5) );

 

is more readable than

 

function($parm1, $parm2, round(($upper+$lower)/2+0.5));

 

It takes extra brain power to manually process that there is a space there and that should be the end of the statement. But when I see a big red bracket, I instantly know it has to be the end. Furthermore, If I have a big complex if statement that has several bracketed conditions in it, I can easily use the arrow keys to go through the brackets and instantly know what goes to what. Try doing that by just looking at it. even with spaces it gets confusing.

[Stooney]

<?php
function($param1=0, $param2=0, $param3=1){

 

No spaces except after the commas, I like default values, and I order my parameters from required->optional, first used->last used.  Just my natural style I've developed over the years.