RE: 20 Tips for becoming a better programmer

May 16, 2013

Regarding “20 Tips for becoming a better programmer”…
http://alfasin.com/20-tips-for-becoming-a-better-programmer/?goback=%2Egde_70526_member_238774726

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
Do A.
Else
Do B.
EndIf

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!”
True.

“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.”
True.
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.”
True.

‘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. ;-)

Advertisements

What if your bug crashes the Mars rover?

January 23, 2011

In “This Developer’s Life” podcast “1.0.3 Problems” mentioned on Scott Hanselman’s blog

Regarding the “1.0.3 Problems” comments about how bad it would be to have written “the bug” that trashed a Mars rover:  I don’t think we have to speculate too much about hypothetical situations.  We have the Hubble telescope mirror, for instance:

http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Flawed_mirror

and the Mars orbiter thing too:

http://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Encounter_with_Mars

“Bummer, dude” is one possible response.


Now Senior Technical Integration Consultant at Guidewire Software

January 22, 2010

I just accepted a position as a Senior Technical Integration Consultant at Guidewire Software, starting the first of next month.


Roller Coasters

June 20, 2009

The “Top Thrill Dragster” roller coaster at the Cedar Point Amusement Park in Sandusky, Ohio caught my eye recently. (One of my relatives spammed me with pictures of it. ;-)

Here are a few links:

For something a little slower, try this:

Found another… a “racing bicycle monorail”, the “Shweeb”, in New Zeland:


Property-Field Transparency

February 6, 2009

I learned Object-Oriented programming (and a great many other things) while working in the Electronic Data Systems (EDS’s) Research and Development department in the late 1980’s. A lot of EDS R&D work was done in an internally developed OO language called “OWL” — a language that was inspired by Smalltalk, had an S-Expression text syntax for code, and could be interpreted by or compiled into C, running on Sun Unix workstations.

One particularly interesting feature of the EDS OWL programming language was that it supported “Property / Field Transparency” — meaning that there was no absolutely no difference, in client usage syntax, between use of “public fields” and the use of “properties” (where data access is mediated through code in getter and setter methods).

The big advantage of Property-Field Transparency is that you can safely DoTheSimplestThingThatCouldPossiblyWork, while writing code, by making all business object fields public. Should you discover later that you need an additional layer of abstraction, you can easily change a public field to a Property, and code the appropriate getter and setter methods, without making any changes to the code that uses that class at all. Thus in languages supporting Property-Field Transparency, you can avoid the source code clutter and maintenance expense of maintaining a great many meaningless repetitive boiler-plate getter and setter methods; and yet you can still quite easily and safely insert them later, where needed, with minimal impact. There isn’t even any need for refactoring support in your IDE, or multiple file checkins.

So it was with great interest that I noticed increasing levels of Property-Field Transparency support in modern languages in recent years: Most scripting languages in the Java environment do this, following the Java Bean standards. (But the Java language itself continues to steadfastly buck the trend!) And in the Microsoft environment, COM and then the .NET environment seem to have embraced support for properties — giving developers fairly good Property-Field Transparency across the board.

But it still annoys and troubles me that most of the industry seems to be avoiding taking advantage of Property-Field Transparency to simplify their code and reduce their costs. Sometimes most of the industry seems to be hooked on “Cargo Cult” practices and ideas — that is, we keep doing things that were the best thing to do at one time, but may no longer be appropriate now — possibly because the practitioners have long since stopped thinking about WHY they’re doing the things they’re doing, and just continue rote practices with the justification that “A great man said that we should do it this way some years go. How dare we question that?”


It was my experience with Property-Field Transparency in the EDS OWL language that inspired me to post some of my ideas on this topic by creating the PropertyFieldTransparency page on one of my favorite web sites, Ward’s Wiki:

See: http://www.c2.com/cgi/wiki?PropertyFieldTransparency