This is closely related to the post on code formatting.

Code can be readable, but still not easily understood. Maybe it reads well but is misleading. Maybe you took the time to pick a good name for that variable, but the way it’s used and what it means has changed, but the name hasn’t. That’s worse than using a cryptic name; at least in the latter case, the reader knows the name is meaningless. If the name is misleading, the reader can make ungrounded assumptions about what’s happening in the code, leading to misunderstanding, and eventually bugs. Also, tragedy.

As I conclude this mini-treatise on a few best practices I hold dear, the overarching theme is simple common sense. As developers, we all too often assume a priori that the only person that will ever touch our code is, well, us. That’s short sighted and a little presumptuous–and frankly, a little defeatist. If your libraries, functions, applications and developmental efforts, whether for your own applications or for clients, are truly useful, they will be refactored, reused, repurposed. That’s really the goal–to write easily understood, fast executing, reusable code.

Why shoot yourself in the foot?