Hey guys!
People are complaining over at Reddit [1] about using PHP, Std, UUID,
... in other words about case.
I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of bikeshedding in the UUID discussion
thread, but it is after all an important question when designing a language.
Our coding standards are extremely unspecific about this kind of
problem, the only thing that is written there is to avoid abbreviations,
and acronyms are not mentioned at all:
https://github.com/php/php-src/blob/master/CODING_STANDARDS#L154-L166
The question is, what would you guys want? The PHP community that
follows the PSR rules is using PascalCase everywhere. The PHP core is
inconsistent:
- PascalCase:
- Spl instead of SPL (Standard PHP Library)
- Abbreviation/Acronym (Java style):
- Intl
- GMP
- DOM
- XML*
I guess that already covers most of the stuff that is actually part of
the core. This is also exactly why I chose to go for UUID and not Uuid.
Personally I am fine with both, but we probably should extend the coding
standards to create a source of truth, or otherwise people will continue
to complain about this.
[1]
https://www.reddit.com/r/PHP/comments/6e24pr/rfc_phpstduuid_namespaced_in_core/
--
Richard "Fleshgrinder" Fussenegger
Hi!
People are complaining over at Reddit [1]
Isn't it what Reddit is for? ;)
I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of bikeshedding in the UUID discussion
thread, but it is after all an important question when designing a language.
I personally don't think it is a very important decision, since nothing
much would change either way, but my preference would be:
- If there's an established acronym, keep it (GMP, DOM, XML, HTTP).
- If it's just words, use CamelCase.
Second preference is all CamelCase, treating acronyms as a single word
(e.g. RpcOverHttpsViaXml).
--
Stas Malyshev
smalyshev@gmail.com
Hey Stas!
Hi!
People are complaining over at Reddit [1]
Isn't it what Reddit is for? ;)
I guess it is. ;)
I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of bikeshedding in the UUID discussion
thread, but it is after all an important question when designing a language.I personally don't think it is a very important decision, since nothing
much would change either way, but my preference would be:
- If there's an established acronym, keep it (GMP, DOM, XML, HTTP).
- If it's just words, use CamelCase.
Second preference is all CamelCase, treating acronyms as a single word
(e.g. RpcOverHttpsViaXml).
Exactly how I see it. I am only asking to decide on one of both and put
it into our coding standard so people who keep on complaining can be
pointed there, and we're done.
--
Richard "Fleshgrinder" Fussenegger
wrote in message
news:86dba466-a764-522b-6990-39fd7668a79c@fleshgrinder.com...
Hey Stas!
Hi!
People are complaining over at Reddit [1]
Isn't it what Reddit is for? ;)
I guess it is. ;)
I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of bikeshedding in the UUID discussion
thread, but it is after all an important question when designing a
language.I personally don't think it is a very important decision, since nothing
much would change either way, but my preference would be:
- If there's an established acronym, keep it (GMP, DOM, XML, HTTP).
- If it's just words, use CamelCase.
Second preference is all CamelCase, treating acronyms as a single word
(e.g. RpcOverHttpsViaXml).Exactly how I see it. I am only asking to decide on one of both and put
it into our coding standard so people who keep on complaining can be
pointed there, and we're done.
I should point out that snake_case was the universal standard decades before
some people switched to 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. That limitation of
the size of names no longer exists in any modern software, so the continued
use of CamelCase is out of habit and not necessity.
--
Tony Marston
wrote in message
news:86dba466-a764-522b-6990-39fd7668a79c@fleshgrinder.com...
I should point out that snake_case was the universal standard decades
before
some people switched to CamelCase.
[citation needed]
Lisp, for instance, uses hyphens to separate words, and has don't since the 1950s.
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]
I'm sorry, but this smells of folklore and guesswork to me. Both underscores and mixed case are workarounds for the inability to include spaces in identifiers, and have their pros and cons, most of which these days come down to opinions on aesthetics.
Regards,
--
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message
news:CEF783BB-8E1F-4A20-9CC6-1364A122BECC@gmail.com...
wrote in message
news:86dba466-a764-522b-6990-39fd7668a79c@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".
Lisp, for instance, uses hyphens to separate words, and has don't since the
1950s.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
I'm sorry, but this smells of folklore and guesswork to me. Both
underscores and mixed case are workarounds for the inability to include
spaces in identifiers, and have their pros and cons, most of which these
days come down to opinions on aesthetics.
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 is not guesswork on my part, it is a documented fact.
--
Tony Marston
"Rowan Collins" wrote in message
news:CEF783BB-8E1F-4A20-9CC6-1364A122BECC@gmail.com...On 31 May 2017 10:26:06 BST, Tony Marston TonyMarston@hotmail.com
wrote:wrote in message
news:86dba466-a764-522b-6990-39fd7668a79c@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.
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.
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.
Regards,
--
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message
news:41F2B884-5DB7-4691-B540-97B0DAEAAFF5@gmail.com...
"Rowan Collins" wrote in message
news:CEF783BB-8E1F-4A20-9CC6-1364A122BECC@gmail.com...On 31 May 2017 10:26:06 BST, Tony Marston TonyMarston@hotmail.com
wrote:wrote in message
news:86dba466-a764-522b-6990-39fd7668a79c@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_identifiersMentions 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
I object to some young nerd arriving on the scene
Please don't make derogatory comments.
Also, this tangent on naming conventions in general is off-topic to
this thread. Please stay on topic.
cheers
Dan
"Dan Ackroyd" wrote in message
news:CA+kxMuTdQv4pG7YQq10p2vFDU4CYV0CWe1D7xWbvCio44PTo9A@mail.gmail.com...
I object to some young nerd arriving on the scene
Please don't make derogatory comments.
A mildly derogatory comment which indicates the low esteem in which I hold
people with such thoughts is not the same as personal abuse, so stop trying
to make a mountain out of a molehill.
Also, this tangent on naming conventions in general is off-topic to
this thread. Please stay on topic.
How can it be off-topic to talk about naming conventions in a thread with
the title "class naming"?
--
Tony Marston
Different groups of people follow different naming conventions simply
because there is no universally accepted standard.
The phrase here is "groups of people"; the PHP Internals team is such a group, and it is perfectly reasonable for that group to follow a naming convention.
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.
Let's just be clear here: you are not being asked to change a single line of your PHP code.
If, at some stage, you want to write a PHP extension, in C, which introduces new classes, AND you want that extension to be distributed and maintained as part of the official distribution of PHP, then you can read the naming conventions once, write your class names in the format it suggests, and all will be fine.
If you never do this, the existence of a convention will make absolutely no difference to you, apart from the benefits, however small, that consistency brings.
Regards,
Rowan Collins
[IMSoP]
wrote in message
news:9dffe898-e550-c6d6-46bd-86dcf74735ea@fleshgrinder.com...
Hey guys!
People are complaining over at Reddit [1] about using PHP, Std, UUID,
... in other words about case.I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of bikeshedding in the UUID discussion
thread, but it is after all an important question when designing a
language.Our coding standards are extremely unspecific about this kind of
problem, the only thing that is written there is to avoid abbreviations,
and acronyms are not mentioned at all:https://github.com/php/php-src/blob/master/CODING_STANDARDS#L154-L166
The question is, what would you guys want? The PHP community that
follows the PSR rules is using PascalCase everywhere. The PHP core is
inconsistent:
The notion that this little inconsistency causes a problem only exists in
the minds of nit-pickers and OCD sufferers. The definition of
"inconsistency" can be taken to ridiculous extremes, as in the following
examples:
- class/method names don't all begin with the same letter - that's
inconsistent. - class/method names don't all contain the same number of characters -
that's inconsistent. - class/method names don't all contain the same number of vowels and
consonants - that's inconsistent. - class/method names don't all contain the same number of uppercase and
lowercase characters - that's inconsistent.
The very idea that there is a "standard" naming convention that everyone
should follow I find most objectionable. The only universal standard is that
every name be readable and convey meaning. Different
projects/teams/organisations are free to use whatever naming convention they
like, be it snake_case, CamelCase, studlyCaps or whatever, and they should
not be forced to change just because some nerd has made a unilateral
decision which is way above his pay grade.
In my project I use a mixture of styles just because I can, but as each name
is readable and conveys meaning it does not cause a problem, therefore does
not require any sort of solution.
There are more important changes which can be made to the language other
than changing it to comply with someone's personal preferences, so this
ridiculous idea should be kicked into the long grass.
Just my personal opinion.
--
Tony Marston
Different
projects/teams/organisations are free to use whatever naming convention
they
like, be it snake_case, CamelCase, studlyCaps or whatever
I think the discussion here is which convention we, as the PHP Internals project/team/organisation, want to use. It's nothing to do with forcing anyone else to do anything at all.
Regards,
--
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message
news:DC66F890-A033-4EFA-8F2B-CB365C8A4FAC@gmail.com...
Different
projects/teams/organisations are free to use whatever naming convention
they
like, be it snake_case, CamelCase, studlyCaps or whateverI think the discussion here is which convention we, as the PHP Internals
project/team/organisation, want to use. It's nothing to do with forcing
anyone else to do anything at all.Regards,
It does not matter. If there was no agreed "standard" to begin with, why
should the core developers be forced to make unnecessary changes just
because someone that there should now be a standard. Who gives this
"someone" the right to demand a change in the name of consistency when the
definition of "consistency" has not even been agreed? If it does not cause a
problem then no time should be wasted in working on a solution.
--
Tony Marston
"Rowan Collins" wrote in message news:DC66F890-A033-4EFA-8F2B-CB365C8A4FAC@gmail.com...
Different projects/teams/organisations are free to use whatever
naming convention they like, be it snake_case, CamelCase,
studlyCaps or whateverI think the discussion here is which convention we, as the PHP
Internals project/team/organisation, want to use. It's nothing to do
with forcing anyone else to do anything at all.It does not matter. If there was no agreed "standard" to begin with,
why should the core developers be forced to make unnecessary changes
just because someone that there should now be a standard. Who gives
this "someone" the right to demand a change in the name of consistency
when the definition of "consistency" has not even been agreed? If it
does not cause a problem then no time should be wasted in working on a
solution.
It is also really irrelevant, as function and class names are
case-insensitve.
cheers,
Derick
@Tony: exactly what Rowan said. We will not change a single line of
code, and nobody will be forced to do anything. UNLESS the code is
meant to become part of the core of PHP. In that case it must follow the
rules, the rules that are part of the coding standard. It is fine if you
change your coding style in every file in your project where you are the
only person working on. However, we are a team if changing members, and
having a consistent code style helps newcomers to get into the code
base. It, hopefully, helps future maintainers to cope better with the
legacy code we are producing every day.
Feel free to disagree with this, but this is reality here, and these
kind of policies are established as part of any professional code base
in the world.
It is also really irrelevant, as function and class names are
case-insensitve.cheers,
Derick
It matters to a lot of people, and that is why it should matter for us.
We are leaders of an unbelievably huge community and we must address
their concerns. Sometimes those concerns are complete bullshit, in that
case we can and should ignore them, but in this case we actually already
have a policy, it is just incomplete and I am asking to complete it. ;)
--
Richard "Fleshgrinder" Fussenegger
wrote in message
news:b1ab1858-8ed9-802b-85a6-fe1b458a479a@fleshgrinder.com...
@Tony: exactly what Rowan said. We will not change a single line of
code, and nobody will be forced to do anything. UNLESS the code is
meant to become part of the core of PHP. In that case it must follow the
rules, the rules that are part of the coding standard.
But if there was no documented standard to begin with then IMHO it is wrong
for someone new to the project to demand that there be a standard, one of
his choosing, and that all existing code be modified to conform to that
standard.
It is fine if you
change your coding style in every file in your project where you are the
only person working on.
I do not consider a particular naming convention (snake_case, CamelCase,
whatever) to be part of my coding standard. The only universal rule that I
have followed for decades is that names be readable, concise and convey
meaning. Anyone who says that they cannot read my code because it uses
snake_case instead of CamelCase I will ignore. I have been using SQL for
decades, and it is case INsensitive and has always used snake_case, which
means that CamelCase is a waste of time.
However, we are a team if changing members, and
having a consistent code style
The term "consistent" can be taken to ridiculous extremes, and I do not
accept extremism in any form.
helps newcomers to get into the code
base. It, hopefully, helps future maintainers to cope better with the
legacy code we are producing every day.Feel free to disagree with this, but this is reality here, and these
kind of policies are established as part of any professional code base
in the world.
If it is so important then why did the PHP project not start off with a
defined standard in this area? If it did not then it could not have been
THAT important.
It is also really irrelevant, as function and class names are
case-insensitve.cheers,
DerickIt matters to a lot of people, and that is why it should matter for us.
Just because it matters to a bunch of nit-picking OCD sufferers does not
mean that it matters to the rest of the world. I deliberately switch between
snake_case and CamelCase in my code just to prove that IT REALLY DOES NOT
MATTER! I can read a name in whatever style it is written, although I have
always preferred snake_case, and being able to read the name and derive
meaning from that name is the only thing that really matters.
We are leaders of an unbelievably huge community and we must address
their concerns.
Addressing the concerns of nit-picking OCD sufferers it not something I
would bother putting on my to-do list. It does not matter what you do, there
will always be someone who will complain that it's wrong. You cannot
possibly please everybody, so you can only aim to please the majority. Those
in the minority you should ignore.
Sometimes those concerns are complete bullshit, in that
case we can and should ignore them, but in this case we actually already
have a policy, it is just incomplete and I am asking to complete it. ;)
Who determined that the existing policy is incomplete?
--
Tony Marston
Hey guys!
People are complaining over at Reddit [1]
While the "STD" is slightly humorous, it is unneeded verbosity, and
will lead to pointless arguments in the future of whether other
features in the future should catch the STD name, or whether they
should be directly under PHP. I would recommend not using it.
I don't care about case, though there may be a slight argument that
upper-casing initialisations is the 'standard' in PHP core.
cheers
Dan
[1] - situation is nominal
Hey guys!
People are complaining over at Reddit [1]
While the "STD" is slightly humorous, it is unneeded verbosity, and
will lead to pointless arguments in the future of whether other
features in the future should catch the STD name, or whether they
should be directly under PHP. I would recommend not using it.I don't care about case, though there may be a slight argument that
upper-casing initialisations is the 'standard' in PHP core.cheers
Dan[1] - situation is nominal
The whole ext/standard (PHP\Std) namespace thingy will be part of a
separate RFC, this is only about the casing and there will be three
choices available to accommodate everyone.
--
Richard "Fleshgrinder" Fussenegger
"Dan Ackroyd" wrote in message
news:CA+kxMuRoMvy6vB0YKd6Ejqu8AsKxrO2x6F9y5i9+cxfJSJ-ihg@mail.gmail.com...
Hey guys!
People are complaining over at Reddit [1]
While the "STD" is slightly humorous, it is unneeded verbosity, and
will lead to pointless arguments in the future of whether other
features in the future should catch the STD name, or whether they
should be directly under PHP. I would recommend not using it.I don't care about case, though there may be a slight argument that
upper-casing initialisations is the 'standard' in PHP core.
It can only be the "standard" if it has been documented as such and everyone
follows it. If it was not documented as such from the start of the project
then it does not qualify. It may have become the most commonly used in a
selection of alternatives, but that does not give anyone the right to now
say that it has become the standard and should be enforced. That strikes me
as being dictatorial and authoritarian, as well as requiring large amounts
of effort without offering any tangible benefits. I'm "consistency" is not a
valid benefit in my book.
--
Tony Marston
Am 03.06.2017 um 10:10 schrieb Tony Marston:
"Dan Ackroyd" wrote in message
news:CA+kxMuRoMvy6vB0YKd6Ejqu8AsKxrO2x6F9y5i9+cxfJSJ-ihg@mail.gmail.com...Hey guys!
People are complaining over at Reddit [1]
While the "STD" is slightly humorous, it is unneeded verbosity, and
will lead to pointless arguments in the future of whether other
features in the future should catch the STD name, or whether they
should be directly under PHP. I would recommend not using it.I don't care about case, though there may be a slight argument that
upper-casing initialisations is the 'standard' in PHP core.It can only be the "standard" if it has been documented as such and
everyone follows it. If it was not documented as such from the start of
the project then it does not qualify. It may have become the most
commonly used in a selection of alternatives, but that does not give
anyone the right to now say that it has become the standard and should
be enforced. That strikes me as being dictatorial and authoritarian, as
well as requiring large amounts of effort without offering any tangible
benefits. I'm "consistency" is not a valid benefit in my book
that's fine for your personal book, everywhere else consistency belongs
to code quality
Tony,
On 30 May 2017 11:21:38 +0300, Tony Marston TonyMarston@hotmail.com
wrote:
they should not be forced to change just because some nerd has made a
unilateral decision which is way above his pay grade
On 30 May 2017 16:18:21 +0300, Tony Marston TonyMarston@hotmail.com
wrote:
just because someone that there should now be a standard. Who gives this
"someone" the right to demand a change in the name of consistency
On 31 May 2017 12:19:59 +0300, Tony Marston TonyMarston@hotmail.com
wrote:
IMHO it is wrong for someone new to the project to demand that there be a
standard, one of his choosing, and that all existing code be modified to
conform to that standard.
On 02 Jun 2017 10:56:57 +0300, Tony Marston TonyMarston@hotmail.com
wrote:
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?the
On 03 Jun 2017 11:10:39 +0300, Tony Marston TonyMarston@hotmail.com
wrote:
That strikes me as being dictatorial and authoritarian
You're correct that nothing gives any one person the right to demand a
change to
naming conventions or any other element of PHP - hence why nobody here is
making
any such demands or proclamations.
However, what you seem not to recognise is that any person has the right to
suggest or campaign for such a change, regardless of their age, experience
level, pay grade, nerdiness or severity of OCD. To imply otherwise is
offensive.
The purpose both of debating suggestions on this list and carrying out the
RFC
process is to determine if the internals community can reach a consensus
on a
proposal's viability for inclusion in PHP.
Only if and when consensus is achieved will the change be implemented.
There are
no unilateral decisions. To imply otherwise is to fundamentally
misunderstand
how open-source collaboration works.
Furthermore, there is absolutely no prerequisite that a standard must have
been
in place since the project's inception for a proposal to be valid.
None of what I have written above should be news to you, and Rowan has
already
clarified that you are not being forced or even asked to change any of
your own
code. So why do you persist?
""Steven Hilder"" wrote in message news:op.y09fz0b4twp9n2@charlie...
Tony,
On 30 May 2017 11:21:38 +0300, Tony Marston TonyMarston@hotmail.com
wrote:they should not be forced to change just because some nerd has made a
unilateral decision which is way above his pay gradeOn 30 May 2017 16:18:21 +0300, Tony Marston TonyMarston@hotmail.com
wrote:just because someone that there should now be a standard. Who gives this
"someone" the right to demand a change in the name of consistencyOn 31 May 2017 12:19:59 +0300, Tony Marston TonyMarston@hotmail.com
wrote:IMHO it is wrong for someone new to the project to demand that there be a
standard, one of his choosing, and that all existing code be modified to
conform to that standard.On 02 Jun 2017 10:56:57 +0300, Tony Marston TonyMarston@hotmail.com
wrote: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?theOn 03 Jun 2017 11:10:39 +0300, Tony Marston TonyMarston@hotmail.com
wrote:That strikes me as being dictatorial and authoritarian
You're correct that nothing gives any one person the right to demand a
change to
naming conventions or any other element of PHP - hence why nobody here is
making
any such demands or proclamations.However, what you seem not to recognise is that any person has the right to
suggest or campaign for such a change, regardless of their age, experience
level, pay grade, nerdiness or severity of OCD. To imply otherwise is
offensive.The purpose both of debating suggestions on this list and carrying out the
RFC
process is to determine if the internals community can reach a consensus
on a
proposal's viability for inclusion in PHP.Only if and when consensus is achieved will the change be implemented.
There are
no unilateral decisions. To imply otherwise is to fundamentally
misunderstand
how open-source collaboration works.Furthermore, there is absolutely no prerequisite that a standard must have
been
in place since the project's inception for a proposal to be valid.
If there was never a standard to begin with then there should be proper
justification for introducing one now, and I'm afraid that "to be
consistent" is not a valid argument. What problems are caused by this
inconsistency? What is the cost, both in core developer time and application
developer time, to change it? If the benefits are smaller than the costs
then can the change actually be justified?
None of what I have written above should be news to you, and Rowan has
already
clarified that you are not being forced or even asked to change any of
your own
code. So why do you persist?
Because I have been using PHP since 2002, and have been following this group
shortly after, and there is one pattern I have seen over and over again.
After a change has been made in PHP core to enforce a "standard" for nothing
more than "to be consistent", some bright spark will try to enforce it on
the greater PHP community. After all, it is the "standard" right? Why should
there be one standard for the core developers and another standard for the
application developers? Sure that's inconsistent, and as such it must be a
"bad thing".
I disapprove of any change to the language which is purely cosmetic and not
an improvement in functionality. The words that I use to express my
disapproval are an indicator of my level of disapproval. When I describe the
supporters of this RFC as nit-picking, anal-retentive OCD sufferers you may
regard that as derogatory but it is far from being abusive. I am simply
pointing out that supporters of this RFC are spending too much time on
irrelevant and trivial details which will not improve the language in any
way whatsoever.
My words may annoy you, but I am just as annoyed at RFCs like this one.
--
Tony Marston
Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be proper
justification for introducing one now, and I'm afraid that "to be
consistent" is not a valid argument. What problems are caused by this
inconsistency? What is the cost, both in core developer time and
application developer time, to change it? If the benefits are smaller
than the costs then can the change actually be justified?
seriously, if you don't understand the obvious benefits of consistency
when a lot of different people have to deal with source code over a long
period of time likely the discussion with you is pointless and just
wasted time for everybody involved
in the time you wasted with your mails i typically cleanup inconsistency
here and there in a project with 250000 lines of code which dates back
to 2003 to make my own life as core-developer and everybody elses easier
wrote in message news:3cfc0130-e530-64ed-36e8-372b044811a8@rhsoft.net...
Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be proper
justification for introducing one now, and I'm afraid that "to be
consistent" is not a valid argument. What problems are caused by this
inconsistency? What is the cost, both in core developer time and
application developer time, to change it? If the benefits are smaller
than the costs then can the change actually be justified?seriously, if you don't understand the obvious benefits of consistency when
a lot of different people have to deal with source code over a long period
of time likely the discussion with you is pointless and just wasted time
for everybody involved
Seriously, can you explain in words of one syllable the precise benefits of
such a consistency? Can you measure the benefits? Just because some OCD
sufferers like consistency is not a good enough reason. I have been
programming for over 30 years, and in that time I have had to deal with both
snake_case and CamelCase, and while I personally find that snake_case is
more readable, especially with names that contain more than 3 or 4 words, I
have no trouble reading either. Having a mixture of styles does not cause a
problem (except in the minds of OCD sufferers) so IMHO it does not require a
solution. Anybody who says that they cannot work with a mixture of naming
styles is either a liar or Illiterate.
in the time you wasted with your mails i typically cleanup inconsistency
here and there in a project with 250000 lines of code which dates back to
2003 to make my own life as core-developer and everybody elses easier
There are some changes which cause a lot more effort to be wasted. I
remember that the move from PHP4 to PHP5 was made more difficult than it
should have been simply because someone decided that the method/function
names for the XSL extension should be converted from snake_case to CamelCase
just to be "consistent".
The proposed change is purely cosmetic and has absolutely no effect on
functionality, so what is the point? There are costs but no benefits, so can
the change really be justified?
--
Tony Marston
Am 05.06.2017 um 10:14 schrieb Tony Marston:
wrote in message news:3cfc0130-e530-64ed-36e8-372b044811a8@rhsoft.net...
Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be
proper justification for introducing one now, and I'm afraid that "to
be consistent" is not a valid argument. What problems are caused by
this inconsistency? What is the cost, both in core developer time and
application developer time, to change it? If the benefits are smaller
than the costs then can the change actually be justified?seriously, if you don't understand the obvious benefits of consistency
when a lot of different people have to deal with source code over a
long period of time likely the discussion with you is pointless and
just wasted time for everybody involvedSeriously, can you explain in words of one syllable the precise benefits
of such a consistency? Can you measure the benefits? Just because some
OCD sufferers like consistency is not a good enough reason. I have been
programming for over 30 years, and in that time I have had to deal with
both snake_case and CamelCase, and while I personally find that
snake_case is more readable, especially with names that contain more
than 3 or 4 words, I have no trouble reading either. Having a mixture of
styles does not cause a problem (except in the minds of OCD sufferers)
so IMHO it does not require a solution. Anybody who says that they
cannot work with a mixture of naming styles is either a liar or Illiterate
it feels like talking with a blind guy about colors
who said "cannot"?
i can mess up my living room and life still goes on
but i won't
i can live without taking a shower over weeks
but i won't
i could work with someone which has a terrible coding style
but i won't
wrote in message news:a6f250ec-c72a-0522-cbf0-2c7b29ed9aef@rhsoft.net...
Am 05.06.2017 um 10:14 schrieb Tony Marston:
wrote in message news:3cfc0130-e530-64ed-36e8-372b044811a8@rhsoft.net...
Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be proper
justification for introducing one now, and I'm afraid that "to be
consistent" is not a valid argument. What problems are caused by this
inconsistency? What is the cost, both in core developer time and
application developer time, to change it? If the benefits are smaller
than the costs then can the change actually be justified?seriously, if you don't understand the obvious benefits of consistency
when a lot of different people have to deal with source code over a long
period of time likely the discussion with you is pointless and just
wasted time for everybody involvedSeriously, can you explain in words of one syllable the precise benefits
of such a consistency? Can you measure the benefits? Just because some
OCD sufferers like consistency is not a good enough reason. I have been
programming for over 30 years, and in that time I have had to deal with
both snake_case and CamelCase, and while I personally find that
snake_case is more readable, especially with names that contain more than
3 or 4 words, I have no trouble reading either. Having a mixture of
styles does not cause a problem (except in the minds of OCD sufferers) so
IMHO it does not require a solution. Anybody who says that they cannot
work with a mixture of naming styles is either a liar or Illiterateit feels like talking with a blind guy about colors
who said "cannot"?i can mess up my living room and life still goes on
but i won'ti can live without taking a shower over weeks
but i won'ti could work with someone which has a terrible coding style
but i won't
Anybody whose says that using snake_case instead of CamelCase for names
causes any sort of "problem" is exaggerating. I have been using a mixture of
naming conventions for several decades, the only "rule" being that each name
must convey a proper meaning, and I have never had a problem. This matter
does not cause a genuine problem, so it does not need any sort of solution.
--
Tony Marston
Seriously, can you explain in words of one syllable the precise
benefits of
such a consistency?
I will try:
- When we write code, we need to know how to spell the names of things. If the things all have names that look the same, it is less hard for us to guess what the name is. This means we take less time to learn the names, and get less things wrong.
- Our brains are made to spot when things are the same, and when things are not the same. When one thing is not like the things near it, we think "why is that?" This slows us down.
- When we get things wrong, we need to find out what we did wrong. If one way to write a name is wrong, we can spot when we wrote it that way, and know that it is wrong.
- If we make two things that mean the same thing, but do not look the same, we might not spot that we wrote a third thing that does not mean the same thing.
I think there are more things that make it good to have names that look the same, but I hope this helps for now.
Yours,
R
--
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message
news:3351770B-C53E-4062-A91A-D3AA7439F02B@gmail.com...
Seriously, can you explain in words of one syllable the precise
benefits of
such a consistency?I will try:
- When we write code, we need to know how to spell the names of things. If
the things all have names that look the same, it is less hard for us to
guess what the name is. This means we take less time to learn the names,
and get less things wrong.
Words and abbreviations are spelled the same whether you use snake_case or
CamelCase, the only difference is how you show the boundary between one word
and the next. Studies have shown that snake_case is more readable than
CamelCase.
- Our brains are made to spot when things are the same, and when things are
not the same. When one thing is not like the things near it, we think "why
is that?" This slows us down.
Seeing a name written in snake_case does not slow you down. In normal
writing there is a space between each word, but as names in software cannot
have embedded spaces. This is why underscores are used, and this is
infinitely more readable than replacing spaces with a capital letter.
- When we get things wrong, we need to find out what we did wrong. If one
way to write a name is wrong, we can spot when we wrote it that way, and
know that it is wrong.
Writing a name wrong has nothing to do with the difference between
snake_case and CamelCase. My IDE will show me existing names that match what
I am typing as soon as I start typing, so I can easily pick the name that I
want.
- If we make two things that mean the same thing, but do not look the same,
we might not spot that we wrote a third thing that does not mean the same
thing.
If you try to instantiate a class that does not exist, or call a
method/function which does not exist, then you will soon know about it.
Using snake_case instead of CamelCase does not invite more errors.
I think there are more things that make it good to have names that look the
same, but I hope this helps for now.
The only universally accepted "rule" for names is that they be unique and
convey proper meaning. In proper languages all names are case-insensitive as
the ability to write the same name with the exact same spelling but
different case is simply inviting disaster.
--
Tony Marston
"Rowan Collins" wrote in message
news:3351770B-C53E-4062-A91A-D3AA7439F02B@gmail.com...On 5 June 2017 09:14:47 BST, Tony Marston TonyMarston@hotmail.com
wrote:Seriously, can you explain in words of one syllable the precise
benefits of
such a consistency?I will try:
- When we write code, we need to know how to spell the names of
things. If
the things all have names that look the same, it is less hard for us
to
guess what the name is. This means we take less time to learn the
names,
and get less things wrong.Words and abbreviations are spelled the same whether you use snake_case
or
CamelCase, the only difference is how you show the boundary between one
word
and the next. Studies have shown that snake_case is more readable than
CamelCase.
- Our brains are made to spot when things are the same, and when
things are
not the same. When one thing is not like the things near it, we think
"why
is that?" This slows us down.Seeing a name written in snake_case does not slow you down. In normal
writing there is a space between each word, but as names in software
cannot
have embedded spaces. This is why underscores are used, and this is
infinitely more readable than replacing spaces with a capital letter.
- When we get things wrong, we need to find out what we did wrong. If
one
way to write a name is wrong, we can spot when we wrote it that way,
and
know that it is wrong.Writing a name wrong has nothing to do with the difference between
snake_case and CamelCase. My IDE will show me existing names that match
what
I am typing as soon as I start typing, so I can easily pick the name
that I
want.
- If we make two things that mean the same thing, but do not look the
same,
we might not spot that we wrote a third thing that does not mean the
same
thing.If you try to instantiate a class that does not exist, or call a
method/function which does not exist, then you will soon know about it.Using snake_case instead of CamelCase does not invite more errors.
I think there are more things that make it good to have names that
look the
same, but I hope this helps for now.The only universally accepted "rule" for names is that they be unique
and
convey proper meaning. In proper languages all names are
case-insensitive as
the ability to write the same name with the exact same spelling but
different case is simply inviting disaster.
Hi Tony,
I think it's clear at this point that we're never going to agree here. We don't seem to even agree what the topic of discussion is - consistency in general? CamelCase in general? Richard's RFC? the authority to choose things? etc
More importantly, we're not going to change the minds of the people who will actually make this decision by filling the list up with our debates. We're just wasting our own time and everyone else's, so I'm going to stop here.
Regards,
--
Rowan Collins
[IMSoP]