camelCase vs Underscores in PSR-1
PSR-1 does not permit underscores for method names, but it probably should. Also, class names most use StudlyCaps.
By. Jacob
Edited: 2022-03-30 21:47
I hate using camelCase when coding. But, for one particular project I finally decided to use camel case consistently for both variable names and class methods. After all, it seems to oddly be the preference among many developers.
Only problems were due to situations where I could not name a function as I wanted because of readability issues.
Plain and simply, a function called articles_fetch_in_batches() looks better than articlesFetchInBatches.
The same applies for variables, and when writing self-documenting code I think it matters a lot that you can write anything you want without thinking about readability issues due to lack of spaces. Camel case is restrictive, underscores are not. Capitalization is not enough simply due to the fact that we got one- and two letter words. It feels almost like some words are lost when using camel case.
Besides that, it is also an extremely weird obsession some developers have, because it plainly does not matter what you use. You can even mix underscores (snake case) with camel case if you want – editors will suggest and autocomplete just fine regardless. The obsession is so big that it has even been "standardized" in PSR-1 by PHP-FIG.
Issues with camel case
For the most part, I like camelCase for one to two word symbols, but it becomes really ugly when more words are used. The problem is particularly pronounced with method names with one- and two letter words, or if you have a method with an acronym, like exportToHTMLTable() it just becomes less readable. Even worse with "lL" and "iI" situations.
So, in a way you can say, by sticking to stubborn conventions to use camel case exclusively, your insistence on "consistency" where no rules apply actually breaks consistency in other places.
Of course, you could just break with the convention to capitalize acronyms, writing "Html" instead of "HTML", but what if a word ending in "l" is followed by a word starting with "I". There are some situations like that, and it always tends to slow down my coding, since I spend more time trying to come up with alternative names for my functions.
Coding conventions should always be guiding, not a requirement
Already, the PSR-1 coding standard is very exclusive towards developers using underscores, since it declares that we "MUST" use camelCase for method and StudlyCaps for class names. In practice, both requirements are redundant and to be perceived as unnecessarily intrusive and suppressive on our personal preferences, so of course, I do not adhere to PSR-1.
In fact, for this particular camelCase project, I decided to tediously refactor everything to use underscores.
You would sometimes also use a convention for naming files, like abstract classes should have the word "abstract" in their name, or you might decide that all class files goes into lib/. This is fine, but you must realize that other people's code might be incompatible with your conventions.
In practice, we are trying to add functionality that should be part of the filesystem. Ideally, you could just add "tags" to each file individually, and it would somehow display the tag when browsing in your editor or file manager. Personally I dislike having "abstract" or other keywords in my filenames, because it restricts my ability to name the class internally because of autoloading.
With coding conventions, I think there is a real chance that editors will some day auto-switch to the convention preferred by developers (visually), ignoring the style used behind the scenes; would that not be wonderful? No suppressive conventions forced on our code, just pure focus on the code.
Links
- PSR-1 - php-fig.org
Tell us what you think: