"Rowan Collins" wrote in message
news:41f2b884-5db7-4691-b540-97b0daeaa...@gmail.com...
On 1 June 2017 10:16:16 BST, Tony Marston <tonymars...@hotmail.com> wrote:
"Rowan Collins" wrote in message
news:cef783bb-8e1f-4a20-9cc6-1364a122b...@gmail.com...
On 31 May 2017 10:26:06 BST, Tony Marston <tonymars...@hotmail.com>
wrote:
wrote in message
news:86dba466-a764-522b-6990-39fd7668a...@fleshgrinder.com...
I should point out that snake_case was the universal standard decades
before some people switched to CamelCase.
[citation needed]
My first job in computing was with a UNIVAC 1108 mainframe in the
1970s. This used a 6-bit character instead of an 8-bit byte, which meant
that
it could support upper case characters, but not lower case. Where a name
was comprised of several words an underscore separator was used, as in
"end_of_file".
Fascinating, but doesn't make it "universal", or frankly have anything to
do with how we write code 40 years later.
Some people have been writing code for decades, and those practices which
they learnt at the start of their careers tend to stick. As one of these
"old timers" I object to some young nerd arriving on the scene and
proclaiming to the world that he has decided to change the "standards" and
demand that everyone follow. Who gave him the right to change the standards?
Are there standards that he can actually change? Bearing in mind that there
is no such thing as a universal naming standard (apart from names being
readable and meaningful) what gives this nerd the right to say "you cannot
use snake_case any more, everything has to be CamelCase"?
That was only because some software could
not handle long names, but could handle both upper and lower case, so
an upper case character was used instead of an underscore.
[citation needed]
Try reading
https://en.wikipedia.org/wiki/Naming_convention_(programming)#Length_of_identifiers
Mentions absolutely nothing about the origins of CamelCase, which a quick
search suggests is somewhat unknown. One theory is apparently environments
whose character sets had replaced underscore with a left-arrow assignment
operator. Which, again, is fascinating but is as irrelevant to designing
modern languages as the origins of the word "beef" is to ordering a
cheeseburger.
Some studies have shown that that most people find it easier to read
compound names which use the underscore separator. Look at the
following:
https://en.wikipedia.org/wiki/Camel_case#Readability_studies
https://en.wikipedia.org/wiki/Snake_case (first paragraph)
This, however, is at least tangentially relevant to the original topic,
since it shows some reasons to pick one convention over the other.
Different groups of people follow different naming conventions simply
because there is no universally accepted standard. The convention that they
follow is usually down to personal choice, and if their convention produces
readable and meaningful names it is not unreasonable for them to object to
being told that they must now follow somebody else's personal choice for no
good reason other than to be "consistent". If the effort of changing to be
"consistent" has costs but no tangible benefits, then in my book it cannot
be justified and is not worth the effort.
Even more relevant would be studies testing the advantages of having a
convention at all, which I would expect to include increased efficiency and
reduced mistakes because it's easier to remember a list of items that
follow a fixed pattern.
If there is no such thing as a single convention when it comes to naming
functions, classes and methods, then what is the benefit of trying to
enforce one? All you will do is annoy those people who are forced to change,
especially when it means taking a name in a readable format and changing it
to a less-readable format.
Provided that the names used are readable and meaningful, what exactly is
the benefit of enforcing one naming convention over another? Any follower of
CamelCase who says that he cannot read names written in snake_case is either
a liar or illiterate.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
