Well that is very irritating.
Your comment system stripped out all of the IEnumerable ANGLE BRACKET HERE int ANGLE BRACKET HERE bits in my comment. Makes it hard to post comments about generic types, no?
All of those IEnumerables above should be “of int”.
Well that is very irritating.
Your comment system stripped out all of the IEnumerable ANGLE BRACKET HERE int ANGLE BRACKET HERE bits in my comment. Makes it hard to post comments about generic types, no?
All of those IEnumerables above should be “of int”.
I always do string s = string.Empty; because people seem to think that if string s = “”; that the = “” isn’t really important and will delete it.
also, string s = string.Empty is a bit more readable in my opinion. and it doesn’t take much longer to do. it’s st + . + em + enter. that puts in string.Empty. hoooray.
I want to agree, but your example tastes of premature optimization to me. I think the number one factor, the very first concern must be clarity. If your code is not clear, it’s harder to understand, and if it’s harder to understand, it’s harder to know that it is correct.
Clarity first, foremost, and above all else.
Less code comes from higher level languages, and one that’s suited to the task at hand.
That’s why C++ and Java projects take forever. So much code must be written.
I’ve been programming for thirty years and I’m still amazed at the discussion of this age old thought about programming. At first, I thought everyone gets what Jeff is saying. I’ve heard it said many times. The comments don’t lie, though.
The answer - stop defending your technique, lose your ego, keep “Code Complete” next to you when you’re writing and read it, read real production code as much as possible, sharpen your technique, simplify, simplify, simplify …
Hey Jeff. You made some good points. I’m gonna think some more about this.
I love your blog
I want to second the suggestion about Googling for Error Messages, I’ve often found it far nicer than what the MSDN standard output can be. If you DO write the article, contact me via the web site, I have a hilarious “Get Fuzzy” comic that would apply.
I find it funny how many people immediately look at the code and provide the “alternate” solution as opposed to looking at the concept itself. I’ve become a BIG fan of the maintainability camp over the last couple years and I think the “proper” solution is one that is efficient now and understandable later. You can use the if s == “” statement, but there better be something else to explain why this is happening, or maintenance is a bear later.
You may be using an empty string to indicate that a parameter wasn’t specified, and I may update it to change empty string to “Nothing”, thinking it would be more efficient and I’ve just ruined the app.
I came across a quote a few months back that sums this blog up:
You have a choice: fast, good, cheap.
Pick any two.
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
Antoine de Saint-Exupery
Clarity, not brevity is the thing that should be put on a pedestal. Brief code isn’t necessarily clearer code. Sometimes a terse line of code needs to be split over several lines so that the engineer can clearly see what’s happening. Based on your view though, this is bad because there is more code to “break”. I disagree.
That said while I agree with the spirit of your argument, but you misinterpreted Wil Shipley’s blog. He was talking about adding unnecessary complexity and functionality before it was really needed, not using the most concise representations available to the language.
The main issue is simplifying the problem domain. Programmers who have less insight have a tendency to think everything is a special case and spew out code to deal with all of these special cases. Programmers with insight can factor out all of the common elements. It isn’t uncommon to see code that can be rewritten in the same language, be more robust and be 1/10 the size.
There is a tradeoff point though. Code that is more powerful and concise often hits a point where it is difficult for many programmers to grok. If all programmers were top notch then lisp variants would be all the rage. So it all depends on your team. If they are top notch use recursion, lambda functions and all the rest. But in some shops you really have to watch the power/clever vs. lengthy/weak/simple trade off. Good code is (unfortunately) like any other kind of writing. You have to write it to the skill level of your audience.
I honestly don’t see what’s so hard to code cleanly and clearly. For most software, I mean. It’s just tedious. Just follow what the actual concepts are, by definition, and KNOW where you are sacrificing good design for optimization.
OOP and coding exactly to the definitions of things will always get you the correct results. Because whenever you get a problem, it will correspond to a real world problem, and then you document how you decided to fix it. If the problem is optimizing something, THEN you have to make some assumptions / hacks to make things work faster. Document them, because they are going to limit your program.
But given enough time and no optimizations, your code should be awesome.
“Make everything as simple as possible, but not simpler.” - Albert Einstein.
I agree with less code == less bugs … for the most part. Unless that bit of code that you left out introduces other bugs - this I have seen.
One point of contention … code does not rot … had a clueless manager one time that said the same thing. Rot implies that the code changes randomly … it does not, heuristic programming aside.
Code, unless it is dynamically generated, is static unless someone changes it. The compiled result might degradate, due to the media that it is stored on, but the code itself does not “rot”. It might get mangled, broken or munged but it does not rot.
As someone who’s had to do a LOT of maintenance over the years, I strongly disagree with this.
It’s true that you should keep the COMPLEXITY of the system to a minimum. But using String.Empty does not increase the complexity of the code at all: it’s the same decision point either way.
Keeping the code “small” does not mean sacrificing maintainability by using meaningless abbreviated variable and function names, for instance.
In terms of maintainability, String.Empty rules out two distinct classes of bug.
Using String.Empty tells the suspicious maintenance programmer, “yes, I really meant that to be an empty string”. And an experienced maintenance programmer is always suspicious.
Why do I get the impression that a lot of people giving advice on how to write maintainable code have never had to actually maintain old code? If you haven’t accumulated several years maintenance experience, in several different companies, with code that’s been through several different generations of programmers; you probably don’t know what the real sources of confusion are.
While a good article your example of String.Empty is plain wrong but not for the reason you think. Ignoring the correct answer of IsNullOrEmpty as pointed out by others, you should always use if(s == string.Empty), again pointed out by others, as the intention is clearer and less jarring to the programmer reading through it afterwards. Which is who you really code is for. When I see people comparing writing == “” I know they haven’t written code on a big project and certainly haven’t maintained that code 
Yes, the sight of huge blocks of code does make me sick but at times brevity leads to the creation of a smaller but illegible block code which is ridiculously hard to debug or expand upon.
Hence at times, writing large but organized code where every entity in the code is meaningfully part of an underlying theme is much better than a single block of unintelligible code.
if (s == String.Empty)
if (s == “”)
The first is better, because “As a software developer, you are your own worst enemy.” Realize that. So everything which helps you keeping your stupidity out of the code you write is a good thing.
What about the typo:
if (s == " ")
What about if during the lifecycle of the programm the definition of empty changes to whitespace? As people mentioned above, best would be
if (s.isEmpty())
or in some languages which prevent null dereferencing (like Groovy)
if (s?.isEmpty())
or use a language with null objects. Beside all that the complexity of the code (CC) is the same for both examples. And modern reading recognition studies hint that people do not read character by character, but by reading patterns and anchors. So from reading and parsing speed probably both are the same too.
“As a software developer, you are your own worst enemy.”
I feel that it would be better to have a definition of whitespace/null/empty that is consistent through all the code. Then it is easy to check for consistency. And you only have to remember one method.
Besides if you want to be fast set a standard then use it.
Anyone but me have to rework code after a code-review just to be consistent? Or do you guys even have code-reviews anymore?