Posted by tizzo on July 4, 2016 at 4:23am
The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.
New issues for discussion:
Updates on existing issues:
- Stop disallowing camelCase for local variables / parameters - is approved and in the core queue for official core approval.
- [Policy, no patch] PHP 5.4 short array syntax coding standards
- Should we require a blank line after <?php? is approved by core and sniff implemented in coder - ratification of this rule is pending.
- [policy, no patch] Standardize indenting on chained method calls has been moved to the core queue for core approval.
- Add type hinting to function declaration coding standards has been moved to the core queue for core approval.
- [Policy, no patch] Delete permission to pad spacing in a block of related assignments has been marked "needs work" and discussion continues for now. Committee to reevaluate.
These proposals will be re-evaluated during the next coding standards meeting currently scheduled for July 12. At that point the discussion will likely be extended, or if clear consensus has been reached one or more policies may be dismissed or ratified and moved to the next step in the process.
Comments
Hm, some items on this list
Hm, some items on this list appear twice, can you delete the outdated lines? (camelCase issue, PHP 5.4. array issue)
Control Structures if/else brackets on separate lines
I'm sure this has been argued over but I just think the format:
if (condition1 || condition2) {
action1;
}
elseif (...)
does not scan well to me, and is contrary to years of use in C, Java, PHP of
} elseif () {styleAlso seems a waste of good screen real-estate!
The process for proposing
The process for proposing coding standards standards changes is documented on the coding standards project page. As per that description, please create an issue there and build support if you have suggestions for changes.
Result type hinting
I added a note about result type hinting on the param type hinting because it is pretty much the same issue. Can't we have it mentioned for code requiring PHP7, just like for scalar param hints ?
PHP Standards Recommendations
This should be obvious enough, but on any issue addressed by PSR-1 or PSR-2, the Drupal conventions should either:
a) Stay as they are
or
b) Adopt the PSR standards (preferred)
For example, the indentation change recommended above for
else/elseifis in alignment with PSR-2, and therefore should be adopted.change spaces to tabs
change spaces to tabs
in what age are we now? in stone or iron?
The process for proposing
The process for proposing coding standards standards changes is documented on the coding standards project page. As per that description, please create an issue there and build support if you have suggestions for changes.
Less prescription
The more picky we are the less people are likely to contribute to Open Source.
Why are we even discussing use of '!=' or '<>' !!
For one thing it means we're focussing on the wrong things, which machines (our compilers) don't care about, so why should we? The general drive of IT is to make machines work the way we like - i.e. make them even more flexible to accommodate different human (creative) approaches, so we don’t want to work in the opposite direction.
The only real need for code standards is in the area or source code control - where we want to see just the changes. So the perspective must be to respect the layout of the author (as we do with written language) within some simple guidelines, rather than insist it's all converted into our way of doing things, in minute detail, before we accept it.
So!
The reason we should care
The reason we should care about coding standards is that we want humans to be able to effectively parse the code. When we share a set of standards the consistency makes the code easier to read at a glance than when it is varied.
The general Drupal approach has been to push in the direction of consistency to the point where it's as if all Drupal code were written by one hand.
remove dot at the comment end
really, remove this stuff, it is useless and doesn't make sense, it doesnt add and meaning etc
the best way is, you don't force me to add that dot. i want to be able decide - do i need that dot or not
The process for proposing
The process for proposing coding standards standards changes is documented on the coding standards project page. As per that description, please create an issue there and build support if you have suggestions for changes.