What's more important, for your code to be readable, or for it to be right?
Sorry, nobody gets to reject the premise of the question. If you code at all, you already have an answer, it's written right into the product of your labors.
How about this: What's more important, for your code to be correct, or for it to be fast?
I know my answers, what's yours?
Monday, November 8, 2010
What's more important?
Subscribe to:
Post Comments (Atom)
6 comments:
As the old saying goes, if it doesn't have to be *correct*, I can make it go *really* fast.
You have a software product that handles 100,000 separate scenarios, but then you find it gets one rarely used one wrong. You can fix that case, but all other 99,999 cases will be slower. Your customers using those 99,999 cases don't care about the one wrong case, they just see a slower product. "What are you thinking?" they ask, "how come you people work all year on your product and it just gets slower and slower?"
- and yes, this is a real case, although the numbers aren't real of course.
... and I can produce *thousands* of lines of code in a day, if they don't have to WORK.
When I wrote code in the 70's, it had to be fast because hardware was so limited, and it was easy to get it right because software was so simple. So when I don't worry about fast, that is relative to those days :-). My priorities: 1) Correct, 2) Readable AND UNDERSTANDABLE with no fancy and obscure rountines, 3) fast. I only tackle "fast" at the relatively few pain points from the users viewpoint.
My priorities are as follows:
1) correct;
2) easy to understand;
3) fast.
For the time-critical stuff, swap 2 and 3.
Post a Comment