Regarding “20 Tips for becoming a better programmer”…
Yes, these are some good rules. And an expert programmer not only knows the rules, but also knows when to violate them. Because the rules often conflict. And to achieve the best result often involves trade-offs and compromises.
“1. There should be only ONE single exit point to each method (use if-else whenever needed).”
This is a great structured programming rule. And in the time when individual functions often spanned multiple printed pages, it was a practical necessity – for those who wished to preserve their sanity.
But even and especially with excessively large functions, “guard clauses” at the top of a function that exit quickly when the input parameters are bad or have extreme “special case” values makes sense.
And in these days of object-oriented programming, methods with more than a few dozen lines are questionable. With short methods or methods with an extremely simple repeating structure (switch-case), it can make a lot of sense to have multiple exit points (return statements).
“2. When using if-else, make sure to place the SHORTER code snippet in the if:”
But code that says
If not X then
Will confuse people and rot their brains. When does it “Do B.”? It does B when “not not X”, of course! “Ahhhhhhh! My brain hurts!!!” say most maintenance programmers.
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!”
First, get a cat. Cats are way more cool. ^-^
Yes, what he says is true. There is a time and a place for exceptions. They are for “exceptional” conditions – things that have gone wrong. One hopes that this does not happen very often. Exceptions should *NOT* be used for flow control in business logic.
And exceptions are just about the only way to deal with some circumstances. Such cases may be an indication of bad design in the framework you’re using. Exceptions are just about the only way to stop processing in a SAX parser when you find that there is no good reason to read and process the rest of the file.
“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:”
Generally true – particularly with complex expressions and function/method calls.
“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.”
(Honestly, I don’t know what he’s talking about here. “Proper names?” Like “Jeff Grigg”?)
[Edit: Oh! So he means “meaningful names” (for classes, methods, variables, etc.). Why yes, of course. (And thanks to https://thecaptainnemo.wordpress.com/ for the clarification.)]
“7. Whenever you can use HashMap instead of List/Queue – use it!”
And something that I see faaaaaaaaaaaaaaaaaaaaar more often:
Would you people please ***STOP*** using ArrayList when what you really need is a Set?!? The List interface really should not include the “contains” method. If you’re using the “contains” method on List objects, you’re almost certainly doing it wrong. Try again. :-[
“8. If you can use caching instead of I/O (usually DB) – use caching”
Caching is a highly valuable tool. But it’s not a silver bullet. Be aware of its uses and limitations. There are times when you must not use it. An expert will recognize these situaitons.
“9. If you can parse it using regex – use regex”
Generally, people should use regex a lot more than they do. But as with any tool, it can be abused. (See rule #10, below. ;-)
“10. Do not parse HTML using regex”
Regex may be involved. But honestly, there are a crazy number of most excellent XML parsers available for free in Java.
A competent craftsman has good tools and uses them with skill.
“11. Print to Log.”
True. Beginners and hackers dump text all over the place with System.out.println statements scattered through the code.
“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!”
True. And others. Be an active part of your community. It will do you and others a world of good.
“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.”
Double-plus true. ;->
‘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…”
Comments are a code smell.
The need to write comments to explain what the code doesn’t show is generally an indication that your code could be improved to be more readable. And then you would not need the comments. The one clear exception to this is comments that explain why the code that does what it does. The code itself should clearly express what it does and how. “Why” comments are very useful.
And having said that, I have to agree that comments are often the best and quickest way to add meaning to the code. One doesn’t always have sufficient time or inspiration needed to make the code 100% clear.
“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.”
Strive to learn the keyboard shortcuts for things you commonly do.
(And, more generally, automate tasks that you do often!)
“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
‘Be Sociable, Share!’
There’s a lot of wisdom in there.
(And I do know where you live. ;-)