Parens should tightly surround their contents. Spaces immediately inside parens creep me out; to my eye, they serve no purpose of distinction and actually make code harder to read while I try to figure out why there is a space there.
I also distinguish between function calls and special forms; if "foo" were a keyword, I would want a space between it and the list.
My reasoning in both of these cases is grounded in how I chunk code. Arguments are a list; the parens define the list and are therefore part of it and should be physically close. A function call without parens is not a function call but merely a bare identifier; the parens are part of make it what it is, and should be close to it. The condition of an if statement is not part of the if statement in the same way, and if you leave it too close to the keyword it might look like a function call. So let's make it visually distinct by putting a space there.
That run-on paragraph is in that form because it's a sort of recounting of my stream of consciousness on the subject.
D'A: I sometimes put a space to separate a nested function call to make it easier to count parens on the right, and then I put a space on the left for symmetry.
e.g. foo( bar, bam(baz, bif, biz) )
I like to put a space before the opening paren in a function's definition. Otherwise, I think the definition ends up looking too much like a function call.
Discussion (16)
but how do you feel about curley brackets (braces) after the function list? same line or not?
eg.
foo(bar, bam, baz) {
or
foo(bar, bam, baz)
{
I'm agnostic in that regard, as long as it's consistent. I feel it's clear either way.
However I do feel strongly that the closing brace should be on it's own line.
agreed.
foo( bar, blee, baz ) {
...do stuff...
}
I do like spaces between the opening paren and first element of the list as well as between the last element and paren, though.
Objections?
Parens should tightly surround their contents. Spaces immediately inside parens creep me out; to my eye, they serve no purpose of distinction and actually make code harder to read while I try to figure out why there is a space there.
I also distinguish between function calls and special forms; if "foo" were a keyword, I would want a space between it and the list.
My reasoning in both of these cases is grounded in how I chunk code. Arguments are a list; the parens define the list and are therefore part of it and should be physically close. A function call without parens is not a function call but merely a bare identifier; the parens are part of make it what it is, and should be close to it. The condition of an if statement is not part of the if statement in the same way, and if you leave it too close to the keyword it might look like a function call. So let's make it visually distinct by putting a space there.
That run-on paragraph is in that form because it's a sort of recounting of my stream of consciousness on the subject.
D'A
D'A: I sometimes put a space to separate a nested function call to make it easier to count parens on the right, and then I put a space on the left for symmetry.
e.g. foo( bar, bam(baz, bif, biz) )
Just go with the flow, dude.
Rodney: I agree that it's best to follow coding conventions with whatever project one is working on. This claim is about which convention is better.
Well on PHP I can use function(args, or I can use function (args... PHP doesn't really care about that. I agree though, I don't like spaces -.-
Idon'tlikespaceseither.Theyareevil.
I like to put a space before the opening paren in a function's definition. Otherwise, I think the definition ends up looking too much like a function call.
JR: I find there are enough other cues that there's never that confusion.
OK, I've finally given up on this.
Depends on the language - in C-like languages sure, but others not so much. Lisp, Factor, and Haskell come to mind.
In Lisp:
No space.
I won't speak to the other languages you've mentioned, but I'm guessing you're as reliable there as wrt Lisp.
D'A