Naming Things ============= By Paul Robert Lloyd Monday, 22 December 2014 My contribution to [this year's 24 ways][1] attempts to tackle one of the most difficult aspects of web development, naming things: > Working in-house may mean working with multiple developers, perhaps in distributed teams, who are all committing changes -- possibly to a significant codebase -- at the same time. Left unchecked, this codebase can become unwieldy. Coding conventions ensure everyone can contribute, and help build a product that works as a coherent whole. > > Even on smaller projects, perhaps working within an agency or by yourself, at some point the resulting product will need to be handed over to a third party. It's sensible, therefore, to ensure that your code can be understood by those who'll eventually take ownership of it. > > Put simply, code is read more often than it is written or changed. A consistent and predictable naming scheme can make code easier for other developers to understand, improve and maintain... This is the fourth successive year I’ve been involved with 24 ways (including [last year's redesign][2]), although this article rounds out a year in which I have been deliberately quiet in terms of writing and speaking. I don’t intend for that to be the case in 2015. [1]: http://24ways.org/2014/ [2]: /2013/12/redesigning_24_ways/