programming and human factors
by Jeff Atwood
Rich Skrenta writes that code is our enemy.
Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there's more stuff to move around.Code is produced by engineers. To make more code requires more engineers. Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs. You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.
Rich hints at it here, but the real problem isn't the code. The code, like a newborn babe, is blameless and innocent the minute it is written into the world. Code isn't our enemy. You want to see the real enemy? Go look in the mirror. There's your problem, right there.
As a software developer, you are your own worst enemy. The sooner you realize that, the better off you'll be.
I know you have the best of intentions. We all do. We're software developers; we love writing code. It's what we do. We never met a problem we couldn't solve with some duct tape, a jury-rigged coat hanger, and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code:
The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.In coding, you have many dimensions in which you can rate code:
- Brevity of code
- Featurefulness
- Speed of execution
- Time spent coding
- Robustness
- Flexibility
Now, remember, these dimensions are all in opposition to one another. You can spend three days writing a routine which is really beautiful and fast, so you've gotten two of your dimensions up, but you've spent three days, so the "time spent coding" dimension is way down.
So, when is this worth it? How do we make these decisions? The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to: Start with brevity. Increase the other dimensions as required by testing.
I couldn't agree more. I've given similar advice when I exhorted developers to Code Smaller. And I'm not talking about a reductio ad absurdum contest where we use up all the clever tricks in our books to make the code fit into less physical space. I'm talking about practical, sensible strategies to reduce the volume of code an individual programmer has to read to understand how a program works. Here's a trivial little example of what I'm talking about:
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!
It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity.
If you love writing code-- really, truly love to write code-- you'll love it enough to write as little of it as possible.
There is too much emphasis on patterns and too little emphasis on writing efficient, compact code.
Despite all the methodologies and "project science" software is still bloated, uses too much memory (memory is cheap, so what the heck), slow and/or buggy (in need of hotfixes) or pulls you into the configuration hell (declarative programming, anyone?).
It seems that all advances in hardware design are overtaken by software bloat.
Let's have a looong discussion about pros/cons of singleton pattern :) or parameterless constructors. Let's bloat. Blog. Reboot. Repeat.
Sam on June 13, 2007 3:01 AMWhat if you write two lines of code in your blog which don't really accomplish anything and then about twelve hundred different people write their own version of those two lines. Would that be considered code-effective?
Magus on January 6, 2008 5:55 AMThese kinds of articles encourage people to write three-line loops for 'simplicity' when fifteen lines performing several checks before the operation would be a cheaper solution.
molotov on January 6, 2008 9:28 AMBetter way is to use static method String.IsNullOrEmpty(string).
Brevity should be in term of how you will shorten your code in function or class, not just one silly variable.
Nobody cares which one you use, because IT DOESN'T MATTER.
You really own to yourself to read your article and use proper example. You contradict yourself with the example as it is. It ain't like the 2 lines you got there are hard to understand or one is harder than the other, it's really just saving space like you say you are against before the example. Right after it, you say the first line is better cause it is shorter! What are you saying here, that you want shorter code or clearer code? I understand that you wish the later but you contradict that when you say :
"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!"
Your ideas in your blogs are good but you seem to shoot yourself in the foot with bad examples.
Jonathan D. on January 10, 2008 5:41 AMstring.Empty is more explicit and likely more readable. Therefore it should trump "".
Having said that, if choosing one of those two options is important, then the person choosing is either the best programmer in the world or probably wasting more time than any other programmer in the world...
Calvin on June 10, 2008 8:00 AMI would use if (string.Empty == s) to prevent the common problem of doing an assignment when you intended to do a comparison. The compiler will catch the error for you as you cannot assign to a constant.
There's also an interesting discussion around using either the .net types or the c# types. Do we use Int32 x = 0; or int x = 0; ?
I also agree that the intent is clarity, and not brevity, although clear code can be brief, but sometimes it's a bit long winded. Whatever expresses the intent clearly is why I try to write.
Dauchande on June 19, 2008 4:07 AMI just want to say thank you to all the Pythonistas who reminded me that you can simply use 'if s:. I'd forgotten about that.
I regards to the main thrust of the article (as opposed to silly examples), I agree. In fact, it's one of the major reasons I use Python pretty much to the exclusion of all else. It's syntax is terse, but readble. It's dynamic nature and other goodies reduce boilerplate.
Levi Karatorian Aho on July 12, 2008 11:10 AMI have read many of the comments but one of the issues I have found in maintaining other peoples code as well as updating older code I did not see listed. My favorite debuugging tool is stepping through the code. My greatest obsatcle to this is over-modularization. Any statement of database theory will caution the Database designer against over normalization. If there is no need to break up an Address field into separate fields for house number, Street directional prefix, ,street name, street type, and so on ad finitum then you should not do so.
However, over and over again, in debugging some one else code I will find a method, that calls two other methods that each call two other methods and so on and so on until you reach the point at which the actual task is actually performed in a little one or two line method.
Now I am not advocating a return to spaghetti code or the dispensation of object-oriented methodology. I am merely advocating moderation in everything. If you have to track 15 method calls in 5 different classes to find out one one method is doing, I'd say your code is too convoluted. The first principal in coding as in any field of engineering is KISS.
joeller on July 14, 2008 11:24 AMCode is the implementation of an algorithm. Large code is the result of a bad algorithm. The flexibility offered by modern day programming languages,scripts,etc mean that developers have countless ways to solve the same problem, but at the end of the day, one implementation will be the fastest which is the point of computer science and all that useless jargon that describes abstractions. Depending on your environment, if ur the lone wolf or part of a group, verbosity will become a requirement of the algorithm. Therefore it cannot be considered overhead if is necessary for it to be quickly understood and propagated by numerous individuals. The only other limitation would then be the analysis of the algorithms, a topic bashed to death. I don't see the point of this article, if not to show that, like code, lots of letters can feel up space but are unnecessary. did i just diss mysself?!
Ezrad on July 20, 2008 8:46 AMTaken as a general philosophy, being concise is much better than the alternative. However, my perspective is that regardless of how verbose or structured, the most important aspect of any project is the documentation. Specifically to code development, this means annotation. Identify the problem, articulate the algorythm, distill the essential components, write the code. Annotate the hell out of everything.
David on November 19, 2008 10:08 AMBrevity?
Sp[Sf.E0Z]=function Sp$$E0z(){
var t=this;
if (t[Sf.E0O](c)) {return;}
var s=Z+this.toString();
var a,m=multiline;
var f=Sf.FCC;
var X=f(92),Y=f(47),CR=f(13),NL=f(10),Q=f(34),B=f(32);
var g=g,k=.,[]{}()+=-;+Q+*/^$:!|abcedfghijklmnopqrstuvwxyz_1234567890;
Rf[m]=T;s=s.R(n_R(Y+X+*[^+X+x01]*+X+*+Y,g),Z);Rf[m]=F;
a=[s];
if(s.IO(NL)!=-1) {a=s.P(NL);}else{if(s.IO(CR)!=-1){a=s.P(CR);}}
f=n_F(s,return +Q+Q++(s[L]/s.CCA(0))+s;);
s=a.J(NL);
s=s.R(n_R(X+Y+X+Y+[^+X+n]*,g),Z);
s=f(s);s=s.R(n_R(B,g),Z);
s=f(s);s=s.R(n_R(X+n,g),Z);
for (var x=0;xk[L];x++) {var c=k.CA(x);s=f(s);s=s.P(c).R().J(c);}
var r=Z;
var xi=Math.floor(s[L]/100)+1;
for(var x=0;xs[L];x+=xi) {r+=s.SS(x,1);}
return r+s;
};
I think Scala brings balance among the dimensions mentioned by Wil Shipley. That doesn't mean one cannot write unreadable code in Scala; but as Stuart Halloway states, it captures essence over ceremony.
thSoft on April 22, 2009 3:23 AMI really appreciate it. Very interesting and helpful post.
Sexy costumes on June 30, 2009 10:17 AMgreat post!!
ria on August 4, 2009 4:25 AMHmmm... between code and visual code, I'd go for code all the time.
Try doing SSIS, for instance. It's drag-drop coding at its scariest... errr... finest. :p
Jon Limjap on February 6, 2010 10:08 PM@Jonathan Allen
var result = from x in source select x*x;
vs.
result = [x**2 for x in source]
I gotta say the Python code is a more understandable to me than some quasi-SQL query. ;)
Also, not sure if you know, but:
In the Python code snippet we know that the type of the result is a normal list. What is the type of the result of the C# query? Can you replace "var" with an actual type? If not, can you return the results of the query from a method?
I.e. can you do:
something? Func (Something source) {
return from x in source select x*x;
}
Obfuscated C++ is often very breif.
Use simple code; which isn't always breif.
Shannon on February 6, 2010 10:08 PMI agree with the concept, but think you picked a poor example. The goal is no code - think of a way to do your work without writing custom code.
However, if you need to write custom code, please don't save keystrokes to be "elegant". Once you've crossed over to writing some code, express your intent. For instance, "s" is a terrible variable name since it expresses absolutely no intent. I know it's sample code, but the point is that your logic - "" is better than string.Empty because it's fewer keystrokes - also dictates that "s" is better than "state" or "sorority" or "satanicRitual" or "stepSister".
Unsubscribed! Okay, re-subscribed, but it's probationary!
Jon Galloway on February 6, 2010 10:08 PMlet's all head back to the caves and sharpen our spears... the mastadon are on the move soon
ug son of mug on February 6, 2010 10:08 PMYou're groping at my motto:
"Your code is not complete when there is nothing left to add but when there is nothing left to take away."
Simon.
(foo == String.Empty) vs (foo == "")
(By the way, the second is cleaner. If you don't agree, you can go sit on a tack)
Why is there EVEN a String.Empty value anyway?
MS did a really good job creating pointless entries like that in .NET. What's next, a FooBar type so that n00bs reading documentation can actually compile the examples?
/MSRant
I agree with ALeX, by the way. All I ever use (as a hobbyist) is C and Python.
Adam Marchetti on July 12, 2010 11:44 AMI realize this post is 3 years old now - however it is still available on the web, and its the first time I've read it.
So.. I would like to take issue with your "start with bevity".
Firstly, you should never write code for the compiler, obviously. You should also never write code that "starts with brevity". I'm one of those that will fight you tooth and nail and say that String.Empty is better, by FAR!, than "". As I'm reading a line of code I dont have to stop and translate 'if (someVariable != "")' into 'if some variable not equal to an empty string'. Using String.Empty there just makes it easier to read.
And that's the thing.. one should always wrote code for the HUMAN READER: the next guy that comes along to maintain/tweak/etc your code - even if its you in 6 months.
Boo Ghost on August 13, 2010 7:43 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |