40 Tips for better Programming
How to code better? I collected some tips about self-improvement for programmers. Tips are ordered in no particular order and divided into seven categories.
It was hard, but I excluded some cool tips for sake of simplicity. I didn't mention tricks for programming concurrent software, scalable software, and many more. Optimization tricks were unfairly omitted too.
General tips
These tips are a philosophical counterpart to the rest of this article.
Use priority queue to implement user's requirements. - It is better to implement high priority features or the hardest features first. It minimizes risks of being stuck in the middle of the project.
Fix bugs before writing new code. This is a special case of the first tip. Read more...
Improve yourself. Read books and blogs. There is always something new and useful to read out there.
Have quiet working conditions. It is scientifically proved that you can improve your productivity just by removing distractions. Quite workplace is just the most typical example of this method.
Minimize your work. It is obviously beneficial. Every following programming tip is a concrete example how to do it.
KISS principle. Or 'Keep It Simple, Stupid'. The key value is the simplicity of your system. Some methodologies even put it before the functionality in hierarchy of their priorities. Seeking the simplicity is the key to minimizing your present work. Read more...
Write maintainable code. - To minimize your future work. You can do it by coding readable code and by testing.
YAGNI
Or 'You Ain't Gonna Need It'. Don't pre-implement features that you are not sure are needed. Don't be megalomaniac. Read more...
Less source code is almost always better. It reduces number of bugs. It reduces ugly code.
Don't optimize prematurely. Optimizations require writing less readable and less simple code. You should optimize only when necessary and when you can prove that it will gain indispensable performance. Read more...
Remove dead code. E.g. unused functions. E.g. comments left for possible future use. You use source control software, right?
Don't reinvent the wheel
Don't program code that is already written better, tested, more robust, etc. Read more...
Use best tools possible. Research (use e.g. Google Trends). Use the right tools for the job.
Use version control. This should be obvious. Not doing source backups is amateurish and leads to hell. Shit happens.
Track bugs professionally. Use professional tool. This tip is more important when working in teams. Since this article is not teamwork-oriented, this tip is here by mistake. But, whatever.
Don't repeat yourself
Or DRY for short. Duplication in code (or anything else for that matter) should be avoided. It means that when any change comes up, you'd have to change all the duplicated blocks of code. Read more...
Generate Code. By generating code, you can reduce repetitive tasks when e.g. adding 17th entity to your domain model.
Don't write comments. Comments violate the DRY principle. Your code should be clearly readable without comments. Your code could be self-documented. Also you can document your program with tests and BDD. Read more...
Prefer polymorphism to if/else switch/case statements. Switches have this tendency to reoccur with same cases all over the code. Same functionality could be achieved by proper usage of classes and polymorphism.
Use unchecked exceptions. There is no need to write throws and catches to every using method in your class hierarchy. Don't use checked exceptions. Read more...
Do code reviews. They are good to be sure there is no duplication in code. Also code readability could benefit from them. Read more...
Write readable code
Code readability is good for maintainability of your application and the teamwork. Even if you are the only programmer, you should code readable code. It is possible that you will have to encounter the same code once or twice again in the future.
Use WTF metric. The less number of 'wtf?'s when reviewing your code the better. Another popular formulation is - follow the principle of least surprise. In other words - write readable code. WTF metric is a good heuristics what does the word 'readable' means. Read more...
Choose names carefully. Method names must be meaningful. Variable names too. Every kind of programmer should be able to read your code.
Functions should have one level of abstraction. You shouldn't call high-level business method right next to opening a file for writing.
Function should do one thing. Remember - simplicity. Don't create function beasts that have more than 1000 lines of code and do too much.
Functions should have ideally no arguments. Function arguments hurts readabilty. Return values even more. Ideal number of arguments is zero, than one, two, three. More than 3 arguments are unacceptable.
Write consistently. Following the principle of least surprise. Follow standard conventions of your environment (e.g. J2EE conventions). When you are on legacy code, follow their style.
Don't abuse your programming language. E.g. use varargs for printf-like methods only. E.g. don't use interfaces just to declare constants.
Code in your user's language. You should call your key objects from user's domain the same as the user. Even if he is half-crazy slovak-speaking asshole.
Use Fluent Interfaces in the Builder Pattern. According to Effective Java 2nd Edition, this is the best way to construct objects. This tip is an example of too concrete tips.
Refactor. Always improve your code. Refactor early, refactor often. Read more...
Don't use local variables. After reading Martin Fowler's (the) Refactoring book, I came to a conclusion that he does not like local variables. He almost always tries to refactor them using 'extract method' refactoring. In his opinion this improves readability of methods and also reusability of little pieces of code (those that are extracted). The only exception is when it is not so good to extract method there (the original method is long and uses lots of local variables) AND they have an explanatory purpouse there.
Worship encapsulation
Encapsulation is good. The main purpose is IMO to prevent that stupid everyone else from messing up with your precious code. But it improves readability too, so it is just a subcategory of bigger readability category.
Minimize accessibility of classes and members. Your interfaces should be the simplest possible.
Don't use global variables. Singletons are evil. Static (utility) classes are evil.
Favor composition over inheritance. Improves encapsulation when inheritance is prohibited. I have almost never seen this done in practice. Probably because of violation of much more important DRY rule.
Refer to objects by their interfaces instead of concrete classes. In other words, don't couple by classes, but rather by interfaces.
Loose coupling. Minimize class dependencies to maximize your future options of concrete implementation. Read more...
Apply the Law of Demeter. "An object A can request a service (call a method) of an object instance B, but object A cannot “reach through” object B to access yet another object, C, to request its services." Read more...
Test
Because if you don't, you are working on a legacy code (by definition from 'Working on Legacy Code'). You cannot safely change anything. You don't know if you won't break something when adding functionality. And so on... Even TDD is finally considered good these days. Read more...
Tests should be fast. Otherwise no one will run them.
Test early. Or you hardly will. Read more...
Test often. Before every commit to source control system. Read more...
Test automatically. Because you can.
Use test coverage tool. It is a good metric of your code. Everything should be tested. Anything tested less than 100% smells. Read more...
Fail Fast. Read more...
Code defensively. Check your method parameters for validity. Copy mutable parameters. Copy mutable returned fields. Etc. Read more...
Do daily builds. Read more...
Do you have some good tips I forgot?
It was hard, but I excluded some cool tips for sake of simplicity. I didn't mention tricks for programming concurrent software, scalable software, and many more. Optimization tricks were unfairly omitted too.
General tips
These tips are a philosophical counterpart to the rest of this article.
Use priority queue to implement user's requirements. - It is better to implement high priority features or the hardest features first. It minimizes risks of being stuck in the middle of the project.
Fix bugs before writing new code. This is a special case of the first tip. Read more...
Improve yourself. Read books and blogs. There is always something new and useful to read out there.
Have quiet working conditions. It is scientifically proved that you can improve your productivity just by removing distractions. Quite workplace is just the most typical example of this method.
Minimize your work. It is obviously beneficial. Every following programming tip is a concrete example how to do it.
KISS principle. Or 'Keep It Simple, Stupid'. The key value is the simplicity of your system. Some methodologies even put it before the functionality in hierarchy of their priorities. Seeking the simplicity is the key to minimizing your present work. Read more...
Write maintainable code. - To minimize your future work. You can do it by coding readable code and by testing.
YAGNI
Or 'You Ain't Gonna Need It'. Don't pre-implement features that you are not sure are needed. Don't be megalomaniac. Read more...
Less source code is almost always better. It reduces number of bugs. It reduces ugly code.
Don't optimize prematurely. Optimizations require writing less readable and less simple code. You should optimize only when necessary and when you can prove that it will gain indispensable performance. Read more...
Remove dead code. E.g. unused functions. E.g. comments left for possible future use. You use source control software, right?
Don't reinvent the wheel
Don't program code that is already written better, tested, more robust, etc. Read more...
Use best tools possible. Research (use e.g. Google Trends). Use the right tools for the job.
Use version control. This should be obvious. Not doing source backups is amateurish and leads to hell. Shit happens.
Track bugs professionally. Use professional tool. This tip is more important when working in teams. Since this article is not teamwork-oriented, this tip is here by mistake. But, whatever.
Don't repeat yourself
Or DRY for short. Duplication in code (or anything else for that matter) should be avoided. It means that when any change comes up, you'd have to change all the duplicated blocks of code. Read more...
Running tests require one step. Otherwise no one runs them.
Build requires one step. You are going to do it often.
Generate Code. By generating code, you can reduce repetitive tasks when e.g. adding 17th entity to your domain model.
Don't write comments. Comments violate the DRY principle. Your code should be clearly readable without comments. Your code could be self-documented. Also you can document your program with tests and BDD. Read more...
Prefer polymorphism to if/else switch/case statements. Switches have this tendency to reoccur with same cases all over the code. Same functionality could be achieved by proper usage of classes and polymorphism.
Use unchecked exceptions. There is no need to write throws and catches to every using method in your class hierarchy. Don't use checked exceptions. Read more...
Do code reviews. They are good to be sure there is no duplication in code. Also code readability could benefit from them. Read more...
Write readable code
Code readability is good for maintainability of your application and the teamwork. Even if you are the only programmer, you should code readable code. It is possible that you will have to encounter the same code once or twice again in the future.
Use WTF metric. The less number of 'wtf?'s when reviewing your code the better. Another popular formulation is - follow the principle of least surprise. In other words - write readable code. WTF metric is a good heuristics what does the word 'readable' means. Read more...
Choose names carefully. Method names must be meaningful. Variable names too. Every kind of programmer should be able to read your code.
Functions should have one level of abstraction. You shouldn't call high-level business method right next to opening a file for writing.
Function should do one thing. Remember - simplicity. Don't create function beasts that have more than 1000 lines of code and do too much.
Functions should have ideally no arguments. Function arguments hurts readabilty. Return values even more. Ideal number of arguments is zero, than one, two, three. More than 3 arguments are unacceptable.
Write consistently. Following the principle of least surprise. Follow standard conventions of your environment (e.g. J2EE conventions). When you are on legacy code, follow their style.
Don't abuse your programming language. E.g. use varargs for printf-like methods only. E.g. don't use interfaces just to declare constants.
Code in your user's language. You should call your key objects from user's domain the same as the user. Even if he is half-crazy slovak-speaking asshole.
Use Fluent Interfaces in the Builder Pattern. According to Effective Java 2nd Edition, this is the best way to construct objects. This tip is an example of too concrete tips.
Refactor. Always improve your code. Refactor early, refactor often. Read more...
Don't use local variables. After reading Martin Fowler's (the) Refactoring book, I came to a conclusion that he does not like local variables. He almost always tries to refactor them using 'extract method' refactoring. In his opinion this improves readability of methods and also reusability of little pieces of code (those that are extracted). The only exception is when it is not so good to extract method there (the original method is long and uses lots of local variables) AND they have an explanatory purpouse there.
Worship encapsulation
Encapsulation is good. The main purpose is IMO to prevent that stupid everyone else from messing up with your precious code. But it improves readability too, so it is just a subcategory of bigger readability category.
Minimize accessibility of classes and members. Your interfaces should be the simplest possible.
Don't use global variables. Singletons are evil. Static (utility) classes are evil.
Favor composition over inheritance. Improves encapsulation when inheritance is prohibited. I have almost never seen this done in practice. Probably because of violation of much more important DRY rule.
Refer to objects by their interfaces instead of concrete classes. In other words, don't couple by classes, but rather by interfaces.
Loose coupling. Minimize class dependencies to maximize your future options of concrete implementation. Read more...
Apply the Law of Demeter. "An object A can request a service (call a method) of an object instance B, but object A cannot “reach through” object B to access yet another object, C, to request its services." Read more...
Test
Because if you don't, you are working on a legacy code (by definition from 'Working on Legacy Code'). You cannot safely change anything. You don't know if you won't break something when adding functionality. And so on... Even TDD is finally considered good these days. Read more...
Tests should be fast. Otherwise no one will run them.
Test early. Or you hardly will. Read more...
Test often. Before every commit to source control system. Read more...
Test automatically. Because you can.
Use test coverage tool. It is a good metric of your code. Everything should be tested. Anything tested less than 100% smells. Read more...
Fail Fast. Read more...
Code defensively. Check your method parameters for validity. Copy mutable parameters. Copy mutable returned fields. Etc. Read more...
Do daily builds. Read more...
Do you have some good tips I forgot?
Comments