Follow YAGNI : It is very tempting to write more code then we really need. Since we are already on it lets build the whole damn thing as we are going to need it anyway and then we soon realize oh it is not just the code but it has to be a properly tested code, well designed, easily maintainable and also might change with the change in future feature requirements. With this we end up comprising the quality of the feature which we were building in the very first place. Why code when you ain’t gonna need it for the task at hand?
Let it DRY : Use and reuse code as much as possible which might be either our own code or available frameworks, tools, libraries. There are different ways of putting it avoid code duplication, DRY (do not repeat yourself). The key to enable laziness is abstraction – being modular, loose coupling, DI, separation of concerns (aspects). Reuse becomes harder with the increase in the size of the component we want to reuse so keep it short.
Make the code sweat : Put it under test. With a good fast suite of test, we will get away from the fear of breaking the code when we do refactoring or cleanup. More exhaustive our test suite more confident we feel doing the cleanup. Remember Test Early. Test Often. Test Automatically. I really enjoyed reading these epigrams from Alberto Savoia http://www.agitar.com/downloads/TheWayOfTestivus.pdf
Make your code speak not smell : We have heard quite often about code smells and the way to get out of it is to recognize them very early in the devlopment cycle and get rid of them. These code smells might occur just within a class or can span between classes. Here is a very neat and quite exhaustive list of code smells
http://www.codinghorror.com/blog/archives/000589.html and I tend to believe that most often then not when we are getting rid of code smells we are refactoring
Delegation over inheritance, code against an Interface, DI : We probably all know a lot about it by now but really no essential list dealing with programming tips can be complete without these. Some cool quick reasons
- Decoupling
- Making it unit test enabled
- Non-invasive
- Easily Maintainable
- Abstraction
I can keep filling in the buzzwords but you got the idea.
I will keep adding stuff to this list. Please help me out with your suggestions
