Your coding future decided in hilarious, yet acrimonious way
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Your coding future decided in hilarious, yet acrimonious way
I don't know if many of you have heard about this or care. It seem that a number of guys from the major frameworks got together at php|tek and put together a "PHP coding standards" specification. Most of the ideas are pretty good, but they unwittingly presented it in disastrous fashion. Things went downhill from there. It is pretty funny to read, and very informative to anyone who is interested in PHP at that level (or planning to organize a standards group!).
I don't know whether these guys have taken their discussion off-list after their amazing launch. Read it and weep:
http://news.php.net/php.standards/start/2
I don't know whether these guys have taken their discussion off-list after their amazing launch. Read it and weep:
http://news.php.net/php.standards/start/2
(#10850)
- jaoudestudios
- DevNet Resident
- Posts: 1483
- Joined: Wed Jun 18, 2008 8:32 am
- Location: Surrey
Re: Your coding future decided in hilarious, yet acrimonious way
Totally right, definitely a disastrous fashion! But good ideas.Most of the ideas are pretty good, but they unwittingly presented it in disastrous fashion
I am currently redoing my website with a colaborative feel to it (hopefully go live next week). I am trying to put together a good coding practice standards section for the web technologies/languages I use and other developers I colaborate with. However, I did not take into consideration namespaces yet.
Btw does anyone know when php 5.3 and/or php 6 is going to be released?
Re: Your coding future decided in hilarious, yet acrimonious way
B.S. I see no reason to make that a standard.All classes, interfaces, and abstracts must begin with an uppercase
character.
That's scary stuff. It doesn't seem like they are really putting a lot of thought into anything.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Your coding future decided in hilarious, yet acrimonious way
They were certainly trying to tackle an important problem -- autoloading that understands namespaces. I don't know if the effort has died or they have just taken the discussion private. But it should be a warning to any open source standards effort that starts with "we have decided X, Y and Z already..." 
(#10850)
Re: Your coding future decided in hilarious, yet acrimonious way
PHP and Coding Standards? Well, first there should be a naming convension for the build-in function, and then they can talk about Coding Standards...
hexdec but bin2hex
str_replace but strcasecmp
isset but is_numeric
strcasecmp for case insensitive comparision, but str_ireplace for case insensitive replace
And of course, stdClass but Exception
hexdec but bin2hex
str_replace but strcasecmp
isset but is_numeric
strcasecmp for case insensitive comparision, but str_ireplace for case insensitive replace
And of course, stdClass but Exception
php.net wrote:5.3.0 This function is no longer deprecated, and will therefore no longer throw E_STRICT warnings.
5.0.0 This function became deprecated in favour of the instanceof operator. Calling this function will result in an E_STRICT warning.
Last edited by Darhazer on Fri Jun 05, 2009 5:21 pm, edited 1 time in total.
Re: Your coding future decided in hilarious, yet acrimonious way
Is that how they're actually presenting the ideas to the public, or is that just a link to an email discussion list?
- jayshields
- DevNet Resident
- Posts: 1912
- Joined: Mon Aug 22, 2005 12:11 pm
- Location: Leeds/Manchester, England
Re: Your coding future decided in hilarious, yet acrimonious way
Good points. The worst of all is the needle and haystack parameter order confusion.Darhazer wrote:PHP and Coding Standards? Well, first there should be a naming convension for the build-in function, and then they can talk about Coding Standards...
hexdec but bin2hex
str_replace but strcasecmp
isset but is_numeric
strcasecmp for case insensitive comparision, but str_ireplace for case insensitive replace
And of course, stdClass but Exception
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Your coding future decided in hilarious, yet acrimonious way
The first couple postsare the presentation of the decisions that a small group of guys from frameworks made at the php|tek conference. The whole discussion shows the think blowing-up. I don't know what is going on now as the conversation seems to have stopped there a day or two ago. I assume they have taken the discussion private. I hear that they kicked people off of one the the PHP IRC channels for no reason the other day.onion2k wrote:Is that how they're actually presenting the ideas to the public, or is that just a link to an email discussion list?
It is a standard that will effect PHP programmers in general. The idea is for frameworks to be more interoperable by using common loading/autoloading standards. That is one reason I posted the link.
Here are some more links:
http://www.leftontheweb.com/message/The ... initiative
http://www.travisswicegood.com/index.ph ... ards-group
http://pooteeweet.org/blog/0/1499
(#10850)
Re: Your coding future decided in hilarious, yet acrimonious way
Uppercasing class names is pretty much THE standard already.astions wrote:B.S. I see no reason to make that a standard.All classes, interfaces, and abstracts must begin with an uppercase
character.
- jaoudestudios
- DevNet Resident
- Posts: 1483
- Joined: Wed Jun 18, 2008 8:32 am
- Location: Surrey
Re: Your coding future decided in hilarious, yet acrimonious way
Yep, it is in CakePHP and Zend FrameWorkWeirdan wrote:astions wrote:Uppercasing class names is pretty much THE standard already.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Your coding future decided in hilarious, yet acrimonious way
Me:
{Legend: ProperCase, UPPERCASE, Proper_Score_Case, UPPER_SCORE_CASE, camelCase, camel_Score_Case}
* Class Names: ProperCase except when trying to show domain grouping, such as Employer_Settings and Employer_ControlPanel, which would sort of use a modified Proper_Score_Case.
* Function/Class Method Names: camelCase. (Note -- I only finally decided to switch this year to this, even though it is completely illogical to me. (I'm Old School.) I just wanted to, well, fit in with the New School kids.)
* Constant Names: UPPERCASE where readable, and UPPER_SCORE_CASE where it may read better, on a case-by-case basis.
* Opening Curly Brace: Same line as declaration, always.
* Closing Curly Brace: Shares same indentation as declaration.
* Variable Names: ProperCase but with prefixes ($sFirstName, $oRec, $aoRecords) unless $a, $b, $c, or $i, $j would work in some cases. Prefixes:
g + prefixes = global (so people don't ask, "Where did this variable come from?" -- and used sparingly)
x + prefixes = byref var (meant to return a value back)
a + prefixes = array
rs = recordset
rw = row
s = string
v = variant (any) -- used extremely sparingly
o = object
b = boolean
c = single character
d = date, date/time, time
h = handle
n = numeric (any kind)
(With some minor exceptions on the ProperCase such as: $hDB, $nID, $sIPAddress.)
Also, if I instantiate a class, I am inclined to go without using variable prefixes unless I have a factory item. Example:
$oRec = $DB->getRecord('users','id = 1'); // factory item; used even if getRecord may instantiate a class like ActiveRecord to return it
$Settings = new Settings(); // class item
I also don't buy the common argument, "PHP is a duck-typed language. Using variable prefixes is irrelevant." That's hogwash. I use them even though I'm well aware the language is duck-typed. I use them to let people know I'm really meaning for something to be considered as that variable type. I mean, there's a big difference in the values between:
$bAnswer
$sAnswer
$nAnswer
It makes the code a lot more intuitive when shared with others using variable prefixes.
Note I have started to also carry this forward in my Javascript/jQuery stuff as well.
{Legend: ProperCase, UPPERCASE, Proper_Score_Case, UPPER_SCORE_CASE, camelCase, camel_Score_Case}
* Class Names: ProperCase except when trying to show domain grouping, such as Employer_Settings and Employer_ControlPanel, which would sort of use a modified Proper_Score_Case.
* Function/Class Method Names: camelCase. (Note -- I only finally decided to switch this year to this, even though it is completely illogical to me. (I'm Old School.) I just wanted to, well, fit in with the New School kids.)
* Constant Names: UPPERCASE where readable, and UPPER_SCORE_CASE where it may read better, on a case-by-case basis.
* Opening Curly Brace: Same line as declaration, always.
* Closing Curly Brace: Shares same indentation as declaration.
* Variable Names: ProperCase but with prefixes ($sFirstName, $oRec, $aoRecords) unless $a, $b, $c, or $i, $j would work in some cases. Prefixes:
g + prefixes = global (so people don't ask, "Where did this variable come from?" -- and used sparingly)
x + prefixes = byref var (meant to return a value back)
a + prefixes = array
rs = recordset
rw = row
s = string
v = variant (any) -- used extremely sparingly
o = object
b = boolean
c = single character
d = date, date/time, time
h = handle
n = numeric (any kind)
(With some minor exceptions on the ProperCase such as: $hDB, $nID, $sIPAddress.)
Also, if I instantiate a class, I am inclined to go without using variable prefixes unless I have a factory item. Example:
$oRec = $DB->getRecord('users','id = 1'); // factory item; used even if getRecord may instantiate a class like ActiveRecord to return it
$Settings = new Settings(); // class item
I also don't buy the common argument, "PHP is a duck-typed language. Using variable prefixes is irrelevant." That's hogwash. I use them even though I'm well aware the language is duck-typed. I use them to let people know I'm really meaning for something to be considered as that variable type. I mean, there's a big difference in the values between:
$bAnswer
$sAnswer
$nAnswer
It makes the code a lot more intuitive when shared with others using variable prefixes.
Note I have started to also carry this forward in my Javascript/jQuery stuff as well.
Last edited by volomike on Sun Jun 07, 2009 10:13 pm, edited 1 time in total.
Re: Your coding future decided in hilarious, yet acrimonious way
The entire point of a coding convention is to make you code better with fewer errors. That's it. Anyone who hasn't read Joel Spolsky's article on naming conventions really has no place posting in this thread: http://www.joelonsoftware.com/articles/Wrong.html His point is very straightforward - your variable prefix should tell you what the variable contains in the context of your code. It's not good just having n for every number. That won't tell you that the variable has to contain a money value for example. Using "money" as a prefix, or, I suppose, "nMoney" would make much more sense.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: Your coding future decided in hilarious, yet acrimonious way
Onion - sent you a PM. Thanks.
Re: Your coding future decided in hilarious, yet acrimonious way
Awesome link - many thanks!onion2k wrote:Anyone who hasn't read Joel Spolsky's article on naming conventions really has no place posting in this thread: http://www.joelonsoftware.com/articles/Wrong.html
Re: Your coding future decided in hilarious, yet acrimonious way
Great article. He makes some good points, definitely made me think about ways to improve coding conventions
Why are so few people using Hungarian notation anyway?
Why are so few people using Hungarian notation anyway?