Naming things
My contribution to this year’s 24 ways 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), 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.