Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99291 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23217 invoked from network); 31 May 2017 09:20:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 May 2017 09:20:06 -0000 X-Host-Fingerprint: 62.31.75.76 76.75-31-62.static.virginmediabusiness.co.uk Received: from [62.31.75.76] ([62.31.75.76:2337] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AF/8A-43873-4CA8E295 for ; Wed, 31 May 2017 05:20:05 -0400 Message-ID: To: internals@lists.php.net References: <9dffe898-e550-c6d6-46bd-86dcf74735ea@fleshgrinder.com> <84.AD.34073.59B2D295@pb1.pair.com> In-Reply-To: Date: Wed, 31 May 2017 10:19:59 +0100 Lines: 6 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 62.31.75.76 Subject: Re: [PHP-DEV] Re: Class Naming in Core From: TonyMarston@hotmail.com ("Tony Marston") 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. >On 5/30/2017 3:58 PM, Derick Rethans wrote: >> 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. 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