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)