The Best Code is No Code At All

“If you love writing code-- really, truly love to write code-- you’ll love it enough to write as little of it as possible.”

Is this along the lines of “if you love something, let it go”?

The String.Empty reminds me heavily on VxWorks EOS (End of String). They want ‘while (*x != EOS)’ instead of (*x != 0) or simply (*x). Now, how can I even trust them to define EOS as 0, and how pointless is that?

And after stumbling over enum { TRUE = 1, FALSE = 2 } elsewhere, you are going to be careful with assumptions.

And finally the IsEmptyOrNull crowd probably really wants My.IsInvalid instead. If you don’t accept empty strings, you probably won’t want to accept strings consisting only of whitespace either. And then there was the input validator that thought a city name must have at least four characters. Well, not at 10E 4824N.

My favourite verbose horror is code that doesn’t understand booleans.

eg.

if (a==b)
thesame = true;
else
thesame = false;

…and…

if (thesame == true)

Hopefully I don’t need to say how I’d like those written!

Couldn’t agree more with the content; couldn’t disagree more with the sample. String.Empty isn’t more readable to the compiler - it’s more readable to the human. A non-programmer could understand this (assuming he/she was explained what a “string” is).
Besides that, to me this reinforces another code minimization technique: look in the framework. Some other programmer may see this and think "I didn’t know there was a String.Empty in the framework, what else is there that I don’t know about?).

You (and I guess the people you are quoting) are looking at the problem at the wrong level entirely.
The problem is not bloated code, it is bloated design. Basically, it is over engineering.

Code Brevity is a poor replacement for application of the KISS engineering principle (Keep It Simple, Stupid). Should I declare 4 variables with a single line? How is that any better than using 4 lines?

Also I agree with S.Empty() rather than (S == “”). It is more bug prone and harder to maintain. I could also make the case that it the comparison is in fact more complex code, a binary operation with two operands.

I would also like to note that under-engineering is also a very big issue. If you don’t look ahead, your design (or code) is likely to bite you later.

Wil Shipley’s advice “Start with brevity. Increase the other dimensions as required by testing” is just another way of saying “Don’t exercise forethought! Run along and code. We can always fix it later.”

Hi Jeff, nice piece of article.

Actually I’m not a big fan of the Zen attitude, and your conclusion, though ironic, seems a bit void to me :wink:

Thus I suggest using “necessity” instead of “brevity”. By “necessity” I mean: only add statements that are strictly necessary to prove the code is working.
And because I think “necessity” can take many forms, you can make it more or less “explicit” as a trade-off. By that I mean to make the circumstances under which the code works more or less explicit.
Why I do find interesting to challenge your view? Because it focuses on making the code working (not just nice), and integrating the assumption into it (not just readable).
The full post is here: http://lecoupdansloeil.blogspot.com/2007/06/coding-horror-best-code-is-no-code-at.html

Thanks!

I agree 100% with Jeff. Less is by far better. I am Delphi programmer and work on the following basis.

  1. Get the job done. (a / b = …) [10% of the code] (Customer is 75% happy.)
  2. Ensure user input is correct. (b is not zero, null, 0 or what ever zero is not allowed.) [20 % of code.] Customer is 90% happy.
  3. Add a progress bar [3% of Code.] Customer is 100% happy.
  4. Speed the whole process up [20% of the code, as I have to write custom code for this procedure] (Customer is still 100% happy, although I think I am very clever saving him 10 seconds every day.)
  5. And if I was M$ I would have design a cool user interface that would have slowed down everything by a factor of 10. [47% of Code] (Customer 50% happy, but me daughter of 14 thinks it looks cool!)

The fact of the matter is that 33% of the code has done the job 100%!

Ya missed one:

Understandability.

This is probably the most underrated and yet important of these so called ‘dimensions’ of software development.

I would much rather write a verbose understandable piece of code vs a tight super efficient and impossible to figure out later tribute to my ego.

Don’t get me wrong, there are times when tighter is better (like when you reach home plate) but for most of us we are not writing time critical routines that are controlling the interceptor missile during the last 30 milliseconds.

I have to stand with TheophileEscargot (and numerous others) on this. String.Empty illustrates purpose, whereas “” could be a typo.

You know the rule where you’re bound to make a grammatical or spelling error when you post correcting someone’s grammar or spelling? Perhaps this is an instance of a similar rule, where when you want to make a wide-ranging and perfectly valid (if obvious) point, you inevitably end up picking a non-obvious, borderline example that a lot of people will disagree with.

In other recent news, after the drubbing his book got here, Charles Petzold has decided to make himself feel better in the time-honored manner every child knows: Distract attention from yourself by picking on somebody else…

http://www.charlespetzold.com/blog/2007/05/310543.html

I think the example given here has proved the point which this column wanted to prove. You see there are at least 10 entries discussing the pros and cons of those 2 (just two) lines of code. In real life, this is the time wasted and it did happen here also

Yes, I now regret including this minor example. It is instructive to see how even the tiniest of details can become a point of contention… one programmer’s brevity is another programmer’s idea of sloppy code.

Maybe you have to go the dynamic language route: that’s not sloppy code, I just (added custom language keywords | redefined existing language keywords) to make the code more succint. :stuck_out_tongue:

Jeff,

With all this talk about which languages are best to use and code being quoted, I thought I was reading your fizz buzz article!!! They quote their code and completely forget the topic :slight_smile:

http://www.codinghorror.com/blog/archives/000804.html

That’s one of the reasons why I love the action reaction part of SmallC (Now known as PAWN). You make the event function handler and it runs your code once that happens.

I have never found a coder which doesn’t complain about someone else code, this means that either we have the tendency to be extremly perfectionists with other’s code or that simply we are petulant ass holes that don’t realize that as in art appreciation there is no such thing as the omipowerful voice of all reason and true. There is no such thing as perfect code, PERIOD. Great code depends a lot on who you ask. For the people who pays for it its the cheap one that works fine and gets done in a blink. For developers is the one that is clear short and COMMENTED. For me it depends on the situation… but I never loose pragmatism and self improvement of the target.

Just a humble opinion.

You are asking the wrong question.

Instead of s== “” vs. String.Empty, you should be asking why the empty string needs to be special cased in the first place.

If you want smaller, more maintainable code, get rid of the unnecessary special cases.

Perhaps a better example would have been:

if (false == flag)

if (!flag)

People can probably still find a reason to complain but it’s a much more straightforward example of good, brief code.

This is easy. You should always use String.Empty, and constants in general, because it’s good practice.

I worked at lendingtree.com for a few years. One day one of the business folks came over and asked us if we could change it from 4 offers to 5. We all started laughing. You know why? Because the morons that had started writing the code did things like

If OTF = 4 and Blah 4 then

No way to translate. Please, for the love of god. Don’t write short code. Write good code. Someone else might have to maintain your crap some day.

Perceivability - this dimension is missing
Code is more read than written and the stack size of the human brain is about 3.

if (s == String.Empty)
if (s == “”)

It seems obvious to me that the latter case is better because it’s
just plain smaller. And yet I’m virtually guaranteed to encounter
developers who will fight me, almost literally to the death, because
they’re absolutely convinced that the verbosity of String.Empty is
somehow friendlier to the compiler. As if I care about that. As if
anyone cared about that

Bad example, bad explained, personal believe stated as objective fact.

I’m all for simplicity and maintainability.

if (s == String.Empty)
if (s == “”)

But like the first comment says (GuyNamedNate), String.Empty just seems like the right thing to use even though “” is easier to type.

if (false == flag)
if (!flag)

Its interesting but as the years have gone by I’ve revert from (!flag) to (flag == false). Using (!flag) is again easier but explicitly showing (flag == false) just makes for more readable code, that little ! could so easily be missed whilst flicking through someone else’s code.

I know its stupid but it really annoys me when I have to make a change to code and the original developer has left out the braces, although I’m sure they were just simplifying the code:

Example: If (flag) return var;

I can’t help it but I have to add the braces in…

In Python, you just

if s:

empty strings evaluate as False. Simple and readable!

Couldn’t agree with your example, because you are in a framework and don’t know if tomorrow empty strings will be represented as “\^*0” or as 0xbb or MSDN_Useful_Content.
Indeed, I program mostly in C and in order to avoid lamers to understand my code i prefer:
if(!*pszStr)

When in C++ i use STL so:
if(! string.lenght())
STL are better than any other framework: no null pointers, no bagous arrays, no 100-cpu-clocks for an integer comparison.

Bye