Suggest Agenda items for March 11th 2010 dev chat
Recent comments
newtonsongbird on Suggestions Kim Parsell on Core Contributor Handbook Lance Willett on We’re getting very close… Muhammad Abdi on Core Contributor Handbook Maor Chasen on We’re getting very close…
John James Jacoby 4:16 am on March 5, 2010 Permalink
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.
DD32 6:31 am on March 5, 2010 Permalink
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.
Alex M. 6:43 am on March 5, 2010 Permalink
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.
Nikolay Bachiyski 4:51 pm on March 5, 2010 Permalink
We should make the coding standards a more detailed (especially about spaces) and make automated codesniffer checks on commit.
Peter Westwood 9:58 am on March 6, 2010 Permalink
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.
hakre 7:31 pm on March 7, 2010 Permalink
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.
Matt 12:36 am on March 8, 2010 Permalink
You can easily double-space in your editor.
Spaces in functions, around all operators, etc is the wp-style.
Matt 4:57 pm on March 5, 2010 Permalink
Also preferred.
Peter Westwood 9:54 am on March 6, 2010 Permalink
I’m in the prefer camp – follows my rule of being explicit rather than implicit about intention of code function.
Denis de Bernardy 2:37 pm on March 6, 2010 Permalink
Re all these coding standards discussion, could we — at some point — have a discussion on why we’re supposed to be using:
foo( $bar )
instead of:
foo($bar)
it’s like, honestly, I totally understand the rational with if, while, etc… but for function calls?
Alex M. 6:38 pm on March 6, 2010 Permalink
It’s for legibility.
Denis de Bernardy 8:35 pm on March 6, 2010 Permalink
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.
DD32 11:27 pm on March 6, 2010 Permalink
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.
Denis de Bernardy 11:58 pm on March 6, 2010 Permalink
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 )
rather than:
if ( ! $foo )
there’s absolutely no point in adding the space before the negation opterator.
Alex M. 2:54 am on March 7, 2010 Permalink
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.
Denis de Bernardy 3:16 am on March 7, 2010 Permalink
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.
Andrew Nacin 9:09 am on March 8, 2010 Permalink
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.
Peter Westwood 10:05 pm on March 10, 2010 Permalink
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.