Quite often in PHP model code (at least in my own such code) there are direct references to MySQL table and field names, and since MySQL identifiers are for the most part case-insensitive I typically use the under_score naming convention to make those identifiers a bit more readable.
At the same time however, it seems that most folks use camelCase conventions when they create PHP class libraries, and I've been trying to do that, too.
On top of that, the PHP built-in functions themselves are inconsistent. Some of them use camelCase, others use under_scores, and others use C-style naming (for example "strtolower").
The result is that the code tends to be much less readable than I prefer, what with mixed camelCase, under_score, and C-style naming conventions showing up quite near each other in the code.
How are other folks dealing with this? Perhaps there's some way people have found to organize their work so that the different naming conventions tend not to appear quite so close to each other? Or perhaps there are class libraries that if used properly, tend to make things a bit cleaner? I know these discussions of style can get heated -- no need to go there, just some practical suggestions please!
As teresko says, MySQL names are case sensitive on *NIX platforms and insensitive on Windows. If you develop code to support both (as I do) then mixing your cases can cause huge headaches: for example, dump a database on Windows and restore it onto *NIX and all your cases are lost. We actually had to kludge code to detect and fix the cases in a dump just for this reason.
If you're free of Windows though it doesn't really matter what you use, as long as you keep it consistent.
When it comes to models & database tables, you can use:
CamelCase for model names,
plural form of your model's name for database table (with consistent lower/uppercases, like eg. 'camelcases'),
table names in alphabetical order, separated by underscore (eg. 'camels_cases' being connection table between 'cases' and 'camels'),
For classes I would generally use CamelCases (beginning with upper case) and camelCases for methods (beginning with lower cases).
But, in fact, what counts is consistency and readability. It may be a good idea to follow naming conventions of some of the well known and widely implemented frameworks, such as Zend Framework (this one provides pretty precise guidelines as far as coding standard is concerned), but eg. Kohana may be also a good idea. Reinventing the wheel may not be the best idea ;)
Related
I've been learning PHP and see there is a lot of variability in how people name stuff. I am keen to at least be consistent with myself.
Where should I be using Camel Case and where should I be using underscores?
Thoughts:
Variables / Properties: $userid or $user_id or $userID
Classes: MyCustomClass or myCustomClass
Functions / Methods: my_custom_function() or my_Custom_Function()
Any thoughts appreciated.
From the PSR basic coding standard (https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md)
Class names MUST be declared in StudlyCaps (ie: PascalCase).
Class constants MUST be declared in all upper case with underscore
separators.
Method names MUST be declared in camelCase.
This guide intentionally avoids any recommendation regarding the use
of $StudlyCaps, $camelCase, or $under_score property names.
<?php
namespace Vendor\Model;
class Foo
{
const VERSION = '1.0';
const DATE_APPROVED = '2012-06-01';
private $StudlyCapsProp = null;
protected $camelCaseProp = null;
public $under_score_prop = null;
public function fooBar()
{
}
}
Many people have many different preferences and for the most part they're often just that, preferences. Beyond it being what people are used to or that it's popular, there's rarely any rhyme of reason as to why the average person prefers a particular style. Unfortunately that tends not to give you any idea of why to use any particular convention when it comes to more practical matters.
Many people rely on PSR, which eases the task of having to establish conventions. In any development team conventions should be established to ease consistency. The PSR's can save some time versus doing it yourself. Although a useful start, you should not feel that PSR suggestions are authoritative. It's ultimately up to you how you write your PHP but if you are starting from scratch you should first investigate how others do it. That doesn't mean you have to do it the same way, but it's a start.
PSR has certain limitations:
It is established by consensus rather than any particular science meaning that it tends to be inconsistent.
It's not entirely thorough. You'll eventually find situations for which it doesn't specify any options.
It was originally intended to improve compatibility between frameworks but it now includes include matters of taste rather than compatibility. In a great many cases which convention you use will have about as much impact on compatibility as which colour your socks are will have on them fitting your feet.
Compatibility between frameworks tends to be of little or not significant concern for many if not most projects. Especially for closed source commercial projects.
They are purely suggestions from an unofficial third party. Someone may prefer to stir their coffee counter clockwise and recommend that over the internet but in reality which direction you stir it is up to you or the team that you're on. Starbucks, Nero and Costa might release a joint statement recommending that you stir clockwise but you don't need to listen to them if you don't want to.
Putting that aside there are a couple of semantic and practical differences between camel case (camel) and snake case (snake).
The immediate difference is that camel uses a character less to separate words; it's more compact. This might not always be so if you convert your object to JSON and then compress it to send to the browser. Though in most cases the difference will be negligible, camel will in some cases compress more or less efficiently. You're not likely to have to worry about this. In general there a very trivial and insignificant performance differences across the board between the two.
Compactness comes with a price, both from a human perspective and a programmatic perspective. It can be more difficult to separate and work with terms. There's a reason we unzip our files to work on them before zipping them up again and although more subtle the same principle applies here, compact is harder. In a sense it's also lossy, that is the delimiter mutates the character. It's inconvenient as it doesn't always apply to the first character. You can't simply split and join by case. One of the reasons that's important is for dynamic access or meta coding where properties and methods might be determined automatically for example by assembling a set of tokens.
If I created a generator that would automatically create objects to represent tables in a database and to serve as a repository then I might generate methods on that class to be able to fetch by each column. I could be looking at either get_by_username|get_by_email or getByUsername|getByEmail.
If I had (get_by|getBy)($field, $value) then I would be passing username or email for the field, those are the original forms. In this case I have to ucfirst each field when creating the class. Taking this a step further what if I provide these dynamically through __call? In that case each time I need to convert the camel with at least lcfirst where as using snake case all I have to do is bolt it on to the end of the string, it maps one to one without transformation or worrying so much if it's at the end or the start. Consider mapping to two fields (such as operation and field) to a class member:
lcfirst if append or capitalized, split by case, map lcfirst to second onwards
split, map ucfirst to all if append otherwise to rest, concat
Versus:
split
join
Snake preserves the token in its original form by default and if not it tends to be easier to transform easily separated words individually.
It's very common to use meta coding in PHP to get the most out of it which would include a fair amount of string based runtime polymorphism. You're fairly likely to eventually encounter a case where you'll find more benefit with snake than camel where you want to code dynamically.
ifCamelCaseWereReallyThatGreatEveryoneWouldBeAnsweringProgrammingQuestionsOnStackOverFlowLikeThis. asYouCanSeeForAnythingButTheShortestPhrasesShortFormQuicklyBecomesTiring. youCanUsuallyGetAwayWithItInProgrammingAsItsInSmallDosesAndInASeaOfWhiteSpace. anotherAnnoyanceWithCamelCaseIsWhenYouHaveAbbreviationsOrSingleLetterWords. itNotAllGood.
Semantically people also tend to use snake to namespace and do not use it with phrases. Conversely camel tends to be used for small phrases or sentences that read in plain English sequentially or as a title. That's particularly common in OOP where the classname tends to offer the first and most commonly needed layer of categorisation and today tends to increasingly permit nested namespaces (fully supported in PHP). If you're doing something categorically, that is combining words from sets in different categories in order rather than combining words in English to create a phrase then the convention is to use snake. It's also more likely in that case what you'll find yourself doing meta coding.
For example database_statement_row_read_next() isn't entirely a valid or typical English phrase. Where as Database\Statement::readNextRow at the end becomes a valid and standard English expression.
Although English is more comfortable and familiar it has certain problems. Things aren't always in the same order or said the same way when they could be (it's inconsistent) which again might makes it more awkward with meta coding where it's natural to work with sets of words and to combine them without worrying about sometimes needing two instead of one word, order or words, turns of phrase, etc.
If you're writing out names to be fragments of plain English as a rule of thumb you should use camel primarily because that's overwhelmingly the convention used. If you don't strictly care about the order of the words matching up with the order they should be in in English but do care about categorisation and organisation then explicit delimiters tend to be the standard.
What they don't tell you about camel is that by convention you're nearly always expected to write it while also adhering to English grammatical rules which doesn't always workout as well as categorical naming in occasional circumstances.
More correct terms would be:
underscore delimited = alpha_beta
case delimited = alphaBeta
capitalised case delimited = AlphaBeta
In the last case the first upper case doesn't delimit.
In the programming world in general using case delimited (mixture of capitalised and uncapitalised) tends to be the standard for OOP. Generally speaking you would generally end up being more consistent sticking to that in PHP as well, especially for any OOP related names such a methods.
Conversely for procedural, functional and local variables there's a fairly strong tendency among popular languages for them to use snake.
Whatever you opt for try to be consistent as possible and where there are difference you should have both a reason and a convention for that. If you're mixing the two then you might put one behind a facade. Camel tends to be intended for human consumption and to be read as valid English where as snake if needed for meta coding might be something you can nest behind a facade.
Specifically for your proposals:
Variables / Properties:
userid will become hard to read and also end up creating other words. It also would not be possible to translate it to another standard format.
user_id is fine.
userId is fine
userID is bad. That it would translate to user_i_d rather than user_id.
Classes:
MyCustomClass is a universal and very consistent standard that also makes sense in that classnames are titles and should be capitalised.
myCustomClass Might make it look like someone put a method when they meant to put a classname.
Functions / Methods:
my_custom_function This is the simplest thing that could possible work (within reason) though out of the convention of not sticking to English grammar but English words using it to namespace you could just call it function_custom or function_default.
my_Custom_Function isn't the simplest thing that could possible work. The capitalisation is redundant and serves no purpose those it reveals a hidden benefit of dedicated character delimited, it can preserve case.
Some people might be lulled into using both to offer one or more level of nesting. What ever you to for that it'll end up ugly. It's the same concept as CSV within CSV or a two dimensional array. Both camel and snake are used to represent an array of single words. If you want to represent two arrays of words then you'll need something special such as a combination of the two or more than one delimiter which might include a multiple character delimiter. If you're in that situation it's very likely a case of YAGNI as in practice camel or snake on their own is nearly always enough. If you're going to mix them up that should be part of a strategy that's more than superficial and either documented or obvious.
A relevant example of this might be the get_by_username|get_by_email case. I might decide to always have [$operation, $field]. Both operation and field might need to be described with more than one word each. This might lead to using camel for both field and operation but snake to separate field and operation. That would give for example getBy_username, deleteBy_username or getBy_firstName. It's not beautiful but might be argued to serve a practical purpose. It's also somewhat common to start with snake to provide a namespace and then end with camel which is essentially what you get using OOP namespaces, classes and methods. It's not wrong to mix things up if for good reason but more often than not a mix of styles like this tends to instead be a bad code smell that leads you to an unflushed toilet.
Based on the framework we are using, it can be different. We should follow the naming convention that is followed by the framework we are using to develop application.
Each framework follow different naming convention. Example:
Zend does not permit underscores
Symfony also encourages camelCase
Wordpress encourages underscores and does not like camelCase
CodeIgniter also promotes underscores
So: Use whatever your framework uses or create your own naming convention.
But for the basic naming conventions for PHP developers, I have found this to use.
For Variable
We can use lower case underscore. Like
$first_name = "John";
$last_name = "Doe";
(most of the php developer and frameworks like LV uses this. Also wordpress use this naming convention to declare variable.)
For Constants
We can use ALL CAPS case. Like
define('DB_HOST', 'localhost');
define('DB_USER', 'db_user');
(most of the php developer and frameworks and CMS use this naming convention to declare php constant.)
For Class Name
We can use pascal case. Like
class UserDetails {
//
}
(PHP frameworks like LV use this convention and many php developer use this naming convention.)
For Function and Class Method Name
We can use camel case. Like
function getName() {
// Do something
}
(PHP frameworks like LV use this convention and many php developer use this naming convention.)
Note: But wordpress follow lower case under_score to declare function.
function get_name() {
// Do something
}
You can get more details here.
I am working on a web application with a couple of colleagues for the moment. It have turned out that we all have our own way of naming the classes, methods or whatever functions that we currently are writing.
This is starting to get really annoying already so I know that we have a iceberg ahead if we continue like this.
Obviously the best way is to find one routine and stick to it - but how should that specific routine look? - What is common sense when naming pieces, objects, functions or whatever? Are there any standards out there?
Thanks a lot!
One standard you could adopt is the Zend Framework standards
You can take a look at the following: http://www.dagbladet.no/development/phpcodingstandard/
My work has implemented this, and while I don't always agree, at least it spawns consistency.
Take a look at the PEAR Coding Standards. It's pretty comprehensive and would make things easier if you ever use any pear packages.
It also might help to look up CRUD (Create Read Update Delete) on Wikipedia.
As for singulars vs plurals, I tend to try to stick with the conceptual style of my code. I find that with OOP, object names generally tend to be easier to wrap your mind around when you use singulars.
Even if your class is going to comprise information about multiple Dogs, instead of naming it Dogs, name it something else, like Pack, even if it's not technically a pack. It's easier to wrap your mind around multiple Packs than multiple Dogs's, and a "pack" is conceptually stronger than an amorphous group of "dogs". "Dogs" doesn't sound like a single object, whereas "pack" does.
I guess this is an obvious example, but if your class is only going to be used to define objects on an individual basis, don't make it plural. Or if your function is going to format only one string at a time, don't call it formatStrings().
Arrays are a little different. If you use an array for a list of all your dogs, you wouldn't name it $pack, because you'd expect that to contain information about a pack. Instead, you'd name it $dogs.
Use namespaces. Get together and come up with a logical namespace hierarchy policy, then use logical names within the namespaces for the elements.
Sit down with your colleagues, explain the problem you are watching develop, and then write down a standard that you all agree upon.
As you've identified, the only problem is consistency. Therefore, do not convince yourself that you also need a standard that is scientifically-proven to be optimal.
I am new to php and i have seen rather Ambiguous function name convention in php and this confuses me as i regularly forget function names. I suppose i should give you an example.
If function for encoding is htmlentities then why it's opposite is named html_entitiy_decode rather than something like entitiesdecode or the one which is more close to htmlentities.
There are matching function names too but i think php does not have a consistent approach to naming its functions.
Any ideas please as it makes hard for me to remember function names. Thanks
No, PHP doesn't really have a consistent approach to functions names -- that's mainly for two reasons :
Historical reasons : once functions have been released with those names, they can't be changed
Extensions / libraries : PHP is a "glue" language that incorporates several external libraries, and it often used the names of the functions of those libraries -- which are not necessarily consistent.
Fortunately, the PHP community and developpers are aware of that, and try not to repeat this mistake now, when they develop new functions -- but things will most likely remain like this for old functions.
The best you can do is to adopt one naming convention for your classes/functions/methods/variables, and respect it in your projects ; that'll already be a good start.
There is somewhat related question and answer in the PHP FAQ about parameter order:
I cannot remember the parameter order of PHP functions, are they random?
PHP is a glue that brings together hundreds of external libraries, so sometimes this gets messy. However, a simple rule of thumb is as follows:
Array function parameters are ordered as "needle, haystack" whereas String functions are the opposite, so "haystack, needle".
The first sentence of the answer can be applied to function naming as well.
For your own functions, have a look at the Userland Naming Guide and/or consider following one of the Coding Conventions like Zend or PEAR.
I'm afraid that this is a problem with PHP that you're going to have to live with. You could wrap these "misnamed" functions with your own, but that will obviously make calling those functions more expensive.
I would give simple answer, the fact is that it is because of compatibility. A function once given a name can not be reversed as it has been used in thousands of projects and the language core as well as pear and pecl. Thanks
The PHP (PEAR, Zend, etc) coding standard specifies that class names should be in upper CamelCase, while methods and variables (associative arrays keys probably as well) should be in lower camelCase format. The rationale for having classes in CamelCase and underscores is to emulates namespaces and create a parallel with file location, but somewhat I find that where it works well for classes it doesn't so much for variables.
Lets say you have to map some variables to your database columns or form elements. MySQL is not case sensitive (that I know of), neither is html, therefore $data['userId'] is pretty much the same as $data['userid'] to these. ORMs like Doctrine actually ignore camelCasing for columns and just fetch them in lowercase (or is it mysql just returning them as such). Nobody wants to deal with data that may or may not look like $data['productQuantity'] or $data['productquantity'] depending on where it's been. $data['product_quantity'] on the other hand leaves little ambiguity.
So what is the reasoning behind the current variable naming scheme of the coding standard? What prevents PHP to amend this standard to say that all variables should be in lowercase separated by an underscore (it works since we know that class names should start with an uppercase letter)?
Edit:
Please note that I'm not asking what is the purpose of a standard. I know what they are meant to resolve in general. I'm asking why the variable name standard in PHP is the way it is. i.e. I understand the reasoning behind the class naming scheme and the benefits in adopting it (makes your library compatible with many autoloader out there, etc). But I don't get why camelCasing variable names. Is there a special reason? Can I break away from this with no consequences?
So what is the reasoning behind the
variable naming scheme of the coding
standard?
It makes code:
Consistent
Easily understandable for others at first glance what a variable is
All developers follow the same principles making life much more easier.
PHP was strongly influenced by Java, so it was natural to pick up the naming schemes from there. I'm pretty sure that if PHP was invented today, people would have used a different naming scheme. Now it's pretty much standard though, so changing it isn't really an option.
Not though, that this is a de-facto standard. The PHP language doesn't come with any naming guide. It's mainly driven by various frameworks. (Most notably, PEAR and Zend Framework)
It's just a convention... Like a programming social habit
I have read a lot of popular standards manuals for open source PHP projects.
A lot enforce underscores for variables spaces, and a lot enforce camelCase.
Should global functions and variables be named differently to class methods/properties?
I know the most important thing is consistency, but I'd like to hear some thoughts on this.
What would you recommend?
I find camelCase a little more pleasant to type, because I find the underscore a bit awkward to type.
Don't use global variables.
I avoid procedural coding in PHP, I find OOP is easier to keep things organized. Besides, doesn't PHP have enough stuff in it's global namespace already?
Generally I try to stick to:
Classes are StudlyCaps singular or plural nouns, as appropriate: Item, Row, DB, Items.
Variables are lowercase nouns, singular or plural depending on what they hold: $column, $name
Constants are singular upper-case nouns: DEBUG, TYPE_FOO.
Methods are camelCase, and begin with singular verbs (get, perform, do), followed by a noun (singular or plural) describing what it operates on or returns (getThing(), getThings())
It definitely depends on what you're coding for. If I'm coding PHP or PEAR, I use camelCase. If I'm doing Python/Django, I use under_scores. If I'm writing ELisp, I use dashed-separators.
In PHP itself, almost every native function is underscore separated. Most of the PHP code examples in the documentation are underscore separated.
In most languages I think Camel or Pascal Casing is more appropriate, but I think there's clear history for using underscore separation in PHP.
Zend Frameworks naming convention (Which is based on PEAR) is probably the closest you come to a standard in the PHP world. Personally, I prefer to use lowercase_underscore for variable names, but otherwise I mostly follow ZF's convention.
Update on 10 year anniversary:
These days, there is a standard, which is largely accepted within the community. You should stick with that:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md
Yes, the most important thing is consistency. If you are the lone developer, stick with a method. If you are working with a team, talk to the other team members. Differentiating between globals, functions/methods and classes will make reading the code much easier. For some people camelCase is easier than using_underlines so your team needs to discuss the options and pick a style.
Note: I use underscores for my MySQL table_names, I use UpperCamelCase for MySQL field names:
Normally I use $lowerCamelCase for variable names and class properties, but if it contains the value from a field, I use the $UpperCamelCase field name, or if it is an array of data from a table, I'll use the $table_name. This way I can easily grep for SomeField or some_table and find everything referring to it.
You don't have to use this exact system, but being able to search for all references to a field or table is a huge benefit.
I used to prefer to use camelCase, but for the sake of consistency in bigger applications, I have adopted CodeIgniter's style guide.
Even if you don't use their framework, you can appreciate the work that went into defining clear and comprehensive styles: http://codeigniter.com/user_guide/general/styleguide.html
My goal - whatever the specific format of the name - is adding more information. Does the name improve the understanding of the code and/or express something important?
If it does, great, then you've succeeded in it.
If the name doesn't add anything, why did you bother naming it?
I wrote on this one earlier this week:
http://caseysoftware.com/blog/useful-naming-conventions
I would recommend reading the PEAR Coding Standards. Since PEAR is the official PHP Extension and Application Repository, it can be considered the language's official coding standard.