Manual talk:Coding conventions/PHP/Archive

Assignment expressions
This is neither an error nor is it surprising, and in 5.3x allows direct access to referenced element:

- Amgine (talk) 05:10, 25 August 2012 (UTC)

"comment should be put on its own line." ?
This rule can be found in the Spaces section of these conventions. Apparently it was moved here in r547162. I can't really find the related text in the old rules in the Coding conventions diff between before and after the move so this has been added during the move, please correct me if I am wrong. So does this rule make any sense? Comments are used in the same line with code all over the core code. --Danwe (talk) 12:58, 14 September 2012 (UTC)
 * Since nobody seems to know about this, I have just removed the rule again as described above. --Danwe (talk) 10:01, 27 September 2012 (UTC)

Spacing within brackets
Judging by the examples, I guess we don't use spacing within brackets; so use, e.g.,  rather than , eh? Leucosticte (talk) 17:39, 10 November 2012 (UTC)

Ternary contradiction
It says we don't allow it because it only works in PHP 5.3, before noting we now require PHP 5.3. So the only reason to forbid it would be for reasons of readability.

I think it's a useful occasional shortcut, so we should allow it. But if we want to forbid it, it should just say that's a convention we're setting. Superm401 - Talk 06:52, 11 January 2013 (UTC)

@param format
There are two ways given to use @param:



The first one specifically says, "Multiple types can be listed by separating with a pipe character." so, the only real difference is the colon (ignoring the space for now).

The second is correct. To show examples, isUtf8 (generated doc, code) does it that way, and it is correct in the HTML. The type is italicized on the left (if you inspect it, you'll see the HTML class is "paramtype". There is no extra comma for each parameter in the generated docs.

For an example with colons, you can look at a method called outputFileHeaders (generated doc, code). It has two parameters, one strictly matching the first, and the other with an extra space before the colon.

But both the ways with colon are wrong. You see both colons and in the HTML, and there's a spurious comma after one. There's a lot more inconsistency in other methods. Bottom line, I propose we use:

It's the same as #2 above, except I made the parameter name match our conventions, and removed the second type. To be complete, we can also show:

I'm not proposing a big fix up commit, just that we do this for new code and when we're already touching existing code. Superm401 - Talk 07:30, 11 January 2013 (UTC)


 * +1 But what about  I think it is also used and seems to work fine. --Danwe (talk) 22:19, 11 January 2013 (UTC)
 * It is used, but it actually does not work (maybe it once did, e.g. with PHPDoc) right. Example, Article::_construct (generated doc, code).  Unlike isUtf8], the types are not in the right place, nor do they use the paramtype HTML class.  They're just crammed into the description. Superm401 - Talk 14:20, 12 January 2013 (UTC)

Control structures
This page currently says this: Opinions differ as to whether control structures, , , etc. should be followed by a space; the following two styles are acceptable:

Is it time to pick one, at least for new code?

Some statistics: in mediawiki/core, it seems about 84.7% uses the spacy style. Broken down by keyword:

It looks to me like we should standardize on "spacey". Anomie (talk) 18:58, 22 January 2013 (UTC)
 * +1. --Amir E. Aharoni (talk) 19:06, 22 January 2013 (UTC)
 * . -- Krenair (talk &bull; contribs) 19:26, 22 January 2013 (UTC)
 * I think we already use spaces where most people don't (inside parens). If we now decided not to use them where most people do (after control structures) I would really call our coding conventions perverted. So +1 for spacey here. --JGonera (WMF) (talk) 19:37, 22 January 2013 (UTC)
 * A space before the first opening parenthesis should match all other function calls, instead of having a separate one. Think of the new developers - we break away from most coding practices of other projects, shouldn't we try to minimize the differences rather than introduce more of them? There is no need to have a unique one for control structures - they are already highlighted by the IDE and followed by the indented block. --Yurik (talk) 21:58, 22 January 2013 (UTC)
 * Can you provide examples of popular open source projects which don't use spaces after control structures? I just checked the first that came to my mind (Linux kernel) and it does have spaces. On the PHP front, the most popular web frameworks (Symfony, Kohana, lithium) also use spaces. --JGonera (WMF) (talk) 22:40, 22 January 2013 (UTC)
 * Funny - I just checked linux kernel and gnu specs too, and they have a space after if, BUT they do not have spaces inside the , which balances the visual of the parens. A quick google code search shows over 4 million hits for various projects, but this number is significantly lower than the one with the space. Again, it's not a fair comparison because they don't have spaces inside. What I meant initially was that I don't know any major projects that puts spaces both inside and outside, so we should try to get rid of at least one to match. --Yurik (talk) 01:56, 23 January 2013 (UTC)
 * I'm fine with the status quo, which is also consistent with our JS coding style. Let's not change the standard away from what 84% of the code already uses. --Catrope (talk) 22:08, 22 January 2013 (UTC)