I was asked recently to come up with a checklist for developers to improve code quality. There are definitely a lot of things on the internet for this, but what the hell, here’s my $0.02 worth.
Apart from years of penance and discipline, here’s a few things that should definitely help. This is written targeting C# developers but a large part of it should apply to all developers.
Key things to keep doing daily –
- Refactor – the first version of code that “works”, will more or less suck – it will be un-optimized, violate DRY principle, might have unnecessary code, won’t have enough tests, etc. It’s only refactoring that improves things. So consciously keep enough time to refactor the code once it is in working state. This is the single most important thing that people forget to do – it’s crazy even. With this one single rule, your code will improve several folds in terms of quality.
- Remember that code needs to be read and maintained long after it is written – write code that people will find a delight to read or modify. Try to follow simple things such as –
- Separation of concerns
- Automated testing
- Leveraging type system wherever possible for compile-time guarantees
- Use better language constructs to keep code as concise as possible. A line of code that doesn’t exist is a line of code that can’t have a bug!
- Higher and higher levels of abstractions
- Keep on the lookout for repetitive code, or work that you are doing that did not make you think – for e.g. if you are just copy pasting from another place in the application, it means that there is a strong opportunity to refactor, such that you *don’t need* to copy paste (for e.g. a single method call, maybe with optional parameters for conditional handling).
- Spend more time on thinking than typing – you are a developer not a typist
- Have good typing speed though – you want whatever you think of to come on to the screen without breaking your thought process
- Keep on the lookout for tools that will make life simpler. Resharper for instance, helps you with a lot of silly mistakes.
- Don’t use the tools as a crutch though. For e.g. you should be able to make out good code from bad just by looking at it.
- There will be occasional instances where you need to put in a hack – always keep this as the very very last option. And add enough comments to warn others that this is not a pattern to be followed
- Do not sacrifice long-term maintainability for short-term gains – even if the business asks for it. Simplify things if possible – but don’t compromise quality. (for e.g. we might not make the feature extremely configurable, but still it can follow good coding practices such that it can be added later easily if needed).
Use better languages – F#, Haskell, OCaml, etc. I know you probably want me to tell you how to write better code with C#, but there is a ceiling we *will* hit with certain tools. If you use a kitchen knife to do a surgery, there is only so much you can improve via practices and skill. Just imagine how difficult it would be to do things in C++ and have same kind of quality that we have now with C# code (considering additional overhead in terms of memory management, for e.g.), spending the same effort. Some common C/C++ code bugs (such as memory leaks) just aren’t valid C# code in a lot of cases. There is a similar boost you get with F# and Haskell (where a lot of common bugs in C#, such as run-time null-reference exceptions, are just not valid code in F#/Haskell). That, along with tremendous conciseness, will make code quality better, even for the same developer.