These days I found an interesting post in http://bit.ly/12Fz4Xp talking about 20 Tips for becoming a better programmer. Then Jeff Grigg provided his answers in http://jeffgrigg.wordpress.com/2013/05/16/re-20-tips-for-becoming-a-better-programmer/
This is the reason there are two Re:Re: in the title.
Below are my thoughts:
“1. There should be only ONE single exit point to each method (use if-else whenever needed).”
This is a great structured programming rule.
“2. When using if-else, make sure to place the SHORTER code snippet in the if:”
But code that says
If not X then
It’s generally a bad idea to use “negative logic” in an if statement that has an else clause. It will confuse people.
“3. Do NOT throw exceptions if you can avoid it, it makes your code MUCH slower, if you feel like throwing something and then catching it – go play ball with your dog. If you don’t have a dog get one – they’re awesome!”
Exceptions will make your application slow and make your application unreadable. Use it when you have to.
“4. Do NOT try to do many things on the same line – when you’ll get an error – it will be harder to debug, example how to NOT write your code:”
I really hate statement like
It is hard to read, hard to debug and 60%+ NullPointerException is introduced by this kind of statement.
“5. Look for code pieces that look the same and if you find any – REFACTOR your own code!”
“6. Proper names are a MUST. If you’re not sure, meditate on it for another minute. Still not sure? ask your colleagues for their opinion.”
“7. Whenever you can use HashMap instead of List/Queue – use it!”
For better performance it is true.
“8. If you can use caching instead of I/O (usually DB) – use caching”
Use buffer in java.io package for instance BufferedReader.
“9. If you can parse it using regex – use regex”
“10. Do not parse HTML using regex”
“11. Print to Log.”
“12. Use stackoverflow – not only for asking questions! take a few minutes, every day, and try to answer questions – you’ll be surprised how much you’ll learn from it!”
“13. A rule of thumb: if your method is over 50 lines – split it. If your class is over 500 lines – split it. If you think you can’t split it – you’re doing something wrong.”
I do not like super class super method. Nobody is able to modify it. Keep in mind your code is not for yourself. Even if it is your own application. I can guarantee after a few days you can not do anything agaist your super method.
‘14. Writing a code which is “self explanatory” is great but also very hard, if you’re not sure how “obvious” your code is – use code-comments.’
“15. When writing code comments always assume that the reader doesn’t know what you’re trying to do. Be patient & explain. No one is going to *bug* you because your comment was too long…”
“16. You want to improve? read books, blogs, technical online newspapers join relevant groups on Linkedin, update yourself with the latest technologies, go to conferences, got the point?”
17. Practice makes perfect: solve code-challenges, join hackathons, go to meetups etc
…and insightful wise postings like this one. ;->
“18. Choose one IDE and study it carefully, make sure you know the major features. Tune-up the keyboard shortcuts – it will make your workflow smoother.”
“19. Whenever you find a bug, before you fix it, write a unit-test that captures it. Make sure it does.”
‘20. Don’t get lazy – RTFM’
‘We’ll finish with two quotes:’
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
– Brian Kernighan
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
– Rick Osborne