Subscribe to this blog and receive notifications of new posts by email.
Join 2,393 other subscribers
Suggest Agenda items for March 11th 2010 dev chat
Peter Westwood, Andrew Nacin, Matt, and 6 others are discussing. Toggle Comments
Kind of a small item, but how do we feel about the use of semi-colons on inline php? http://codex.wordpress.org/WordPress_Coding_Standards doesn’t mention it, and WP handles it randomly.
I think the defacto standard seems to be include them.
Personally, I dont like them in inline php. But it vary between patch submitters & commiters i think, its never really been that much of a dealbreaker for patch inclusion however.
I strongly prefer them. It’s “proper” and if you want to add additional code to that block, then it’s less confusing if it’s already there, especially for the novice.
We should make the coding standards a more detailed (especially about spaces) and make automated codesniffer checks on commit.
We talked about this a few weeks ago in the dev chat – http://wpdevel.wordpress.com/2010/01/21/summary-of-jan-21st-2010-dev-chat/
In general I don’t think that coding standards violations should block commits – it makes them too much of a game.
For me, they are all about ensuring that intent of the code is obvious and that it is easy to read.
Pragmatically, blocking a commit because it has incorrect spacing on a single line is just adding an unnecessary hurdle – it is better to run regular sweeps and fix violations in a separate commit like is often done for whitespace clean-up already.
From now, I think we’re quite away from pre-commit hooks – I think syntax check and coding standard would be nice for those. For CodeSniffer, I started to create a php codesniffer standard that begins to be usefull for me incl. testing documents.
For style all those whitespaces like it is sort of sugested right now (but it wasn’t in the first place, no idea where that came from), to increase the readability I think it’s worth to only write code into every second line then.
For style I prefer less whitespace than more. When you argue to put more whitespace in there everywhere, for a better readability I ask that code is only written on every second line – same for single line comments then.
You can easily double-space in your editor.
Spaces in functions, around all operators, etc is the wp-style.
I’m in the prefer camp – follows my rule of being explicit rather than implicit about intention of code function.
Re all these coding standards discussion, could we — at some point — have a discussion on why we’re supposed to be using:
foo( $bar )
it’s like, honestly, I totally understand the rational with if, while, etc… but for function calls?
It’s for legibility.
So it seems, yeah. I find it for legible when there are no spaces on function parenthesis, personally. Not to mention easier to write. (Also, imagine all the CO2 we’d save by not needlessly hammering that space bar.) I’m sure I’m not the only one who thinks this, too.
I’m in the camp of there being too much whitespace suggested myself.
foo($id) is just as readable(if not more) as foo( $id );
foo($id,$one) is out of the question, needs to have the extra space in foo($id, $one);
_e(‘BlahBlahBlah’); vs _e( ‘Blah Blah Blah’ );
The spaces add nothing to the readability in this case. A fair chunk of core is currently written like this as well i believe.
Exactly. And then, this makes sense:
if ( foo($id) )
that way it’s easy to distinguish language constructs, such as if, while, foreach…, and functions.
along the same lines:
if ( !$foo )
if ( ! $foo )
there’s absolutely no point in adding the space before the negation opterator.
Denis, the de facto standard is already no space after the exclamation point.
I’m personally in favor of the extra spaces around parentheses. It makes it a lot easier to read.
Possibly, but the de facto standard isn’t necessarily the documented standard, and you can be sure that someone will be raising the point sooner or later if it is not.
I find foo( $id ) and foo( $id, $bar, $baz ) more readable than foo($id) and foo($id, $bar, $baz), but that’s just me. My personal preference also doesn’t matter much here, and I aligned my preferences with the coding standard a bit when I first starting contributing.
I generally like spaces after the negation operator, but when appearing before a constant and/or in a line with multiple conditionals, it can occasionally become lost when separated by a space.
I would generally agree that we should not have spaces around __() or _e() — not necessarily all single-argument calls, just the translation functions.
I think has spurred enough discussion here on the blog and doesn’t fit the purpose of the meeting well and we would do better to focus on more important things during the meeting so I am going to leave it off the agenda.
← Meeting summary (live blog), March 4, 20…
Summer of Code wiki page is posted. http… →