As one of the more experienced developers on my team, I find part of my role becomes to promote good coding styles. Anything from separation of concerns, right through to simply breaking down large functions into smaller distinct parts.
Promoting the practices and explaining them is often the easy part, but explaining why is nearly always a challenge. Here are just a few reasons, and common responses that I've come across:
Testability
Put simply, if you've written your code well, your methods perform distinct testable functions, and your concerns are well separated from your UI, to business logic and data access, then your code libraries are well on their way to lending themselves to unit tests. Applications where business logic or even data access is hidden in UI code, or functions stretch to several hundred lines performing many different actions as they go, are virtually impossible to write unit tests for.
The most common response I have seen to this, is that we don't write unit tests. The simple answer to this that we should! And even if we're not now, we may in the future want to build a suite of unit tests to help us maintain the quality and functionality of our deliverables as we introduce change. If we don't code as if we're going to be unit testing, we'll never be able to.
Readability
Code that is laid out well, with short distinct functions, and that follows a consistent set of guidelines (e.g. naming conventions) is more readable. Fact. Applications with good separation of concerns and naming of libraries, are easier to navigate for the developer and make finding the relevant code easier. Single lines of code that perform several functions in one are often a nightmare to understand for other developers looking at your code.
It seems whenever I suggest that someone's code isn't very readable (or, more delicately, that it could be more readable), the response is always "I can read it fine". Well great! But what about the next person that picks up this code and has to figure it out? Readability is to some extent a subjective measure of code quality. Some people will find certain styles easier than others. However certain styles and standards have come to be because the majority find them easier, and find that it saves time when going back over code. Therefore it's a reasonably safe bet that following these standards will mean that the next person to see your code will find it to be readable.
Maintainability
This one's a real stinker. Because no developer ever believes their code will need to change. That belief is almost always wrong though, because requirement change, bugs will need fixing, and things will get refactored. Code libraries with concerns intermingled and with long multi-functional methods are a pig to cut through and change in any way. They just take a lot longer than well separated and laid out code. If I'm fixing a bug in the data layer, I don't want to go anywhere near the UI. Doing so introduces change to an area of the system that doesn't need changing. I want to go to the data layer, find the offending method, fix the bug, then run a unit test that proves the fix worked. The Coding Horror blog once posted that you should:
"Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live"
This, whilst written in jest, is something anyone who's had to maintain poorly written code can relate to. It's a frustrating process and one that will quickly drive you mad!
Pride
The last reason to write good code, is something very simple but sadly overlooked by many. I take pride in the work that I do, both the end results and the quality of the build that went into it. It's been suggested that the end result is all the matters, that the quality of the finished application is enough to be proud of. But a carpenter who builds a table, will take pride in every aspect. Not just the finish, but the joints, fixings, quality of wood, cuts, everything. Not just the parts we can see, but the entire article. They've built the table to the best of their ability, and it's built to last.
The same is true of building applications. The finished product, whilst a very important part of the puzzle, is still just that, a part. The building blocks, the pieces that make up the finished whole, are just as important. A great application that's poorly written, will be overly costly to maintain. What's the point in building the latest and greatest word processor, if the next version will require a huge and costly development effort to add just a few new features?
For me, I take pride in building quality, functional and maintainable applications that not only fulfil the needs of end users, but also developers working on new features and maintaining the product. Through testable, readable and maintainable code, I know I've done my very best to ensure a quality result all round.
