Damien Katz

You are adamantly opposed to function/methods over 20 lines of code.

One of my favourite quotes from Ken Thompson (who apparently knows a bit about computers) is:

I tend to break up a subprogram when there are too many local variables. Another clue is [too many] levels of indentation. I rarely look at length.

It's not an absolute truth, but he does give two pretty good indicators.

The length of a function isn't important - what you're trying to do in that length is... :-)

This kind of quote used to make me disappointed that I never went to university to do computer science. I imagined that such quotes would be thrown out by a teacher, followed by the magic word "Discuss".
Of course, I eventually met some CS students, who disabused me of this romantic notion. ;-)

You model all your code in UML before you write it.

OK, the explanation behind this point makes it more relevant, but stated plainly like this just aims too wide.

I try to make UML models before I write code simply because it helps me understand the problem domain. Of course, modeling to precise, like putting every single private attributte or setter/getter is an overkill -- but your basic classes, relations and interfaces make stuff much more understandable, both to me and anyone who comes after.

Berislav, actually the sentence should be taken quite literally, particularly the "all" in "all your code". UML and modeling tools have a place: helping flesh out high level designs and aiding understanding of the design.

But some people have the ridiculously mistaken belief UML is actually a good way to create systems, to the extent they literally try to model every aspect of a project in UML and have the application code generated from the UML charts. Yikes.

"If you're crappy and you know it, clap your hands ..."

I kind of disagree with the loc and patterns statements.

Aiming for small functions is a good heuristic, I don't think anyone can argue with that. I disagree more with the LOC thing if it means I'm flattening out a very nested function, because that usually means there's some repetition and a good chance for breaking up the responsibility of the algorithm. If it's flat and long, that just means that there's a lot of dull dispatching going on.

As for the patterns thing, I think if patterns emerge, and then maybe you solidify that (and possibly hand off the brunt of the pattern to a canned module or something), that's a good thing. But if you sit down to design something and start looking to make it out of patterns, you're treading down the dark side.

I know copy and paste is bad but on a recent project I did it because I didn't have the time to make a generic function/library properly.

You less-code fanatics! Soon you will be writing so much less code that it will converge on 0 lines proving that your so-called productivity is an illusion. It takes lots of code to implement proper BPEL/WS-*/EJB/MVC/J2EE/*** applications that leverage every pattern in the book! That's the goal. If you happen to produce a working application as a side effect, you can always re-factor it out.

I personally think spending a ton of time on prefix notation for variables and functions makes for crappy code. I don't need to know something is a local scope static integer if the name is descriptive enough to make sense in code. I can't tell you how many times I've seen variable names like: lviTemp, lviTemp1, lviTemp2, etc. just to keep inside conventions for the company. Sometimes notation is beneficial when you have a lot of different levels of scope with many local variables, but as the Thompson quote above says, that should not happen often. As soon as I see code with pviBlahblah and lvstrBlahTemp23 in it, I glaze over.

The only time I've ever found UML useful was on a large project awhile back that I inherited from someone else. I reverse engineered their code and it allowed me to see how crappy their desing was and what I needed to fix.

With respect to bulky mid-tier implementations that consume vast amounts of company time and resource with no real gain, you have to consider the fact that its employing a lot of people to maintain your company's Web-Logic instance(s).

With respect to catching exceptions, why even log them? Just let the problem flow down stream where it takes an order of magnitude more effort to find and fix it.

Ok, on to a less sarcastic comment. With respect to not returning early, the issue is not that it makes the code easier to analyze, it's that you may be closing resources at the bottom of the function that you are opening above one of your return statements. Ever chase down a memory leak or a "too many file pointers open" issue in production? Not fun.

@Mark McConkey:

[Sarcasm] With respect to catching exceptions, why even log them? Just let the problem flow down stream where it takes an order of magnitude more effort to find and fix it.

In the author's defense, he did say:

If you don’t know exactly what to do in the face of a particular error, then let the exception bubble up to a higher level exception handler.

(emphasis added)

I'd agree with you to a point that you do want to log the error as early as possible, so I'd amend his "let the exception bubble up" to "log it and then let the exception bubble up". The argument isn't against logging, but against logging and then doing nothing.

With respect to not returning early, the issue is not that it makes the code easier to analyze, it's that you may be closing resources at the bottom of the function that you are opening above one of your return statements.

Ah, but that's a nice thing about things like Ruby's ensure construct:

  def doing_something
    resource = open_some_resource
    # do stuff
    return if condition
    # do more stuff
  ensure
    resource.close
  end

This code has the benefit of closing the resource not only if you return early, but also if an exception was thrown and not caught before the resource was closed. The language (and other languages have this ability to, not just Ruby) let's me not worry about the actual path.

Damien you are a clown.

Java IS all you'll ever need! ...and I can teach YOU a thing or two about patterns boy.

You missed a key one:

You work in marketing

or

You work for "ACME"

where ACME is whoever your competition is :-)

Nice post Damien. This one was particularly refreshing to me: "You are adamantly opposed to function/methods over 20 lines of code." I've read in books too much that funcations should be small and each accomplish a single simple task. I realized that those functions are great, but sometimes a nice long function is just what you need.

"You can't believe how stupid they are, they constantly forget how to do simplest things and often make dumb mistakes with your applications. You never consider maybe it's your application that’s stupid because you're incapable of writing decent software."

the honest to god truth

I am sorry to crash the party, but since I've read this entire post, I got to wonder - don't you have anything better to do than post things like this? I personally feel pretty bad for taking time to read this instead of reading an article on Ruby, Spring, or whatever else.

I guess that is why you must skim the whole text before reading it. I thought it was an useful article, because in the long run it is better to work on your programming foundation than on the specifics.

Damien, I couldn't agree more with most of your points. But, back in March, I wrote about the 20 lines rule and, obviously, our opinions diverge on this particular point. I recommend reading the comments, there is an interesting discussion with a reader named Greg.

Well spoken. The team member's line I always love is 'We made a mistake a while back and f*ed up X, it'll be a bitch to fix,' actually translated as 'I f*ed up X and was hoping I could ignore it and you wouldn't find out, that's why you've been getting that bug lately.'

You take great pride in the high volume of code you write.

Re: who said multiple returns were bad: Dijkstra, Structured Programming, and provability. Back in the 70s when dinosaurs, GOTOs and I roamed the earth, the stuctured programming movement was born. And while best known for "GOTO considered harmful", single entry/exit was a desire of at least some. Multiple returns may be easier ( and I do them, but with a mea culpa of "//

You don't document your module, classes, method or functions.

I write device drivers in C. You have no idea what you're talking about.

Copy/Paste is actually good... Against RSI...

you have a linux kernel because people don't follow the advice this moron has passed out.

An interesting post, unfortunately it's more of a funny piece than really insightful because a few of your points are a bit too unqualified.

Like the one about function length. I think you'd agree that long functions are bad in a general sense, the good long ones are more of the exception than the other way aorund, but your bashing those that try not to write long functions, rather than those that do...

Another thought...

Your changes require everyone else to re-factor their code around yours. A good programmer can add new features while retaining backwards compatibility with existing code. Of course this isn't always possible but if you frequently are the cause of code breakage then you may be a bad programmer.

More Signs your a crappy programmer

1. You get software certification, especially those architect certifications.

2. You write software articles and software books to get your name out there because you can't keep the job or clients you had in the past. I am amazed that a lot of those in "speaker and author" circuit keep giving free talks as MSDN Tech Ed and Dev Days events and are always available for hire. These people are know by everyone in the industry yet still need to find new clients.

3. YOu have 10, 20 plus years of software experience, yet those are managerial positions.

I agreed with most of this article, but I mostly disagree with multiple returns and necessity of long functions.

It may be possible to have a really long function with lots of exit points, but all of the ones I've seen were just written by a bad programmer who just kept adding stuff to the function until it worked for whatever test case was being run through it. I found these by having a slightly different case that caused the function to behave strangely, and then had to spend a lot of time trying to figure out which path was being taken or what the thing was returning (unsure if it was even related to the problem).

A single return at the bottom means I can do things like wrap it, log it, or even validate it with a postcondition.

But none of these are hard rules. I have C code with gotos and multiple returns. Not so much in java, though. Before I learned Java, I learned Eiffel, which doesn't have the concept of a ``Return'' (or ``goto'' or any such thing). I don't do too much eiffel anymore these days, but I write quite a bit of ocaml, scheme, and a touch of erlang. These languages also don't have ``return'' (although, sure, you can basically make scheme do whatever you want).

Better structured code requires a bit more thought, and the side-effect of that thought might make the software better, but either way, I'll stick with better structure.

Another sign you are a crappy programmer:
You disagree with this article.

Also, you don't need a 100 person python/ruby shop. If you got that many together, I'm pretty sure you'd accidently cure cancer and solve world peace, in like 4 lines.

Just to clarify, I'm not advocating long functions with many returns. If your code is mostly long functions with lots of returns, it's probably a mess.

But my point is that we shouldn't be dogmatic in our approaches to software construction, if something is most cleanly expressed in one long function, then by all means express it in one long function. Simplified code is better code. It's being pragmatic, which gets labeled "hack" by some purists.

You think no function/method should have multiple return points. ...it often simplifies the code to have multiple returns.

I agree with pretty much everything on this list, but I disagree with this one very strongly. Code is never simplified through the use of multiple returns; you are comprehensively mistaken about that. From a high-level wonky point of view, multiple exit points are - by the definition of "multiple" - more complex than a single exit point, and that's that. From a practical man-in-the-trenches point of view, an exit from the middle of a function turns the rest of the function into an (invisible) else clause - which is simpler than an explicit else clause in what way, exactly?

Sometimes a function can be made slightly shorter through the use of multiple returns, but that's in no way the same thing as "simplifying the code." You may have, through long practice, trained your brain to deal with the multiple-exit-point paradigm very effectively. That is also in no way the same thing as "simplifying the code."

As a beginner, I used to write functions with multiple returns. But it became clear that such functions were contributing more than their fair share of bugs, and were much trickier to change correctly than structured code. I changed my ways and I am never even slightly tempted to go back. Typing an extra if() or two is absolutely worth the gains in simplicity and clarity. Ultimately, using properly structured code actually makes my job easier, and that's why I strive to do it.

Code is never simplified through the use of multiple returns; you are comprehensively mistaken about that.

This is generally true, but "never" is too strong. The primary place is this is untrue is guard clauses. For example:

def foo(x, y)
# x and y must both be defined and active and
# can't be the same thing
retval = 0
if x and x.active
if y and y.active
retval = x.calcval + y.calcval
end
end
return retval
end

This can be rewritten in a clearer manner using guard clauses:

def foo(x, y)
# x and y must be defined and active
return 0 if not (x and x.active)
return 0 if not (y and y.active)

return x.calcval + y.calcval
end

Writing code is half science, half art. The latter implies that there are no truly hard-and-fast rules, just general guidelines that should be applied intelligently to the situation at hand. (Check out my comparison of code to prose.) A method with multiple return points is usually an indicator of bad code (probably that it needs to be broken into multiple methods), but not always.

I couldn't disagree with Western Infidels more. Code can be simplified by multiple returns. Take a simple "equals" method for example. Or take any method that is entirely nested because of a condition on the first line.

I don't understand why the return is "invisible". I mean you can see it in the code. The editor emphasizes it and paints it a pretty color. You see a return and you instantly know what happened: the method ended (oh we return a false if the class types aren't equal for example). The funny thing is most of the one return zealots comment their conditional with a PDL return (return false if classes aren't equal).

This point is made clear in some classic computer science texts such as "Code Complete" and "Refactoring".

def foo(x, y) # x and y must be defined and active return 0 if not (x and x.active) return 0 if not (y and y.active)

return x.calcval + y.calcval
end

def foo(x,y)

int z = 0;

if ((x and x.active) && (y and y.active)) z = x.calcval + y.calcval;

return z;

end

return ((x && x.active) && (y && y.active)) ? x.calcval + y.calcval : 0;

How is the three-returns version really better...? I typically find that in the process of avoiding multiple returns, I find a better or more clear way of coding a function than I had to begin with.

All rubbish, I am surprised you are linked from reddit.

Multiple returns from a function work well as long as you adopt the practice of always implementing ELSE for every conditional branch and *not* using a default return at the bottom. This way, you always know what's being returned and you get the compiler to check that every code-path returns something you specified... at least this work for me in Java, C#-ish languages.

Add this one to your list:

"You create dumb-ass lists of vague assertions & present them as gospel." If -you- code like you blog, God help the recipients of your work. Do us a favor and get back to your game of HALO. I can't believe this showed up as a Digg candidate.

BTW, this story has been Dugg:
http://digg.com/programming/Signs_You_re_a_Crappy_Programmer_(and_don_t_know_it)_2

I know one language.

Sometimes I use patterns, sometimes I use UML, sometime I use cases or multiple returns, sometimes I write long functions, sometimes I use strong typing, sometimes I don't.

If I find myself using more than two loop iterations or my code looks like it has too many indents, I reevaluate what I'm trying to do - and break up my logic so the next guy can read and follow it or add new functionality.

I like to write tight code, it's pretty.

Sometimes, all the time.

Alright, so I'm a student at the Milwaukee School of Engineering and currently studying Software Engineering. This is a very prestigious school (4th in the nation), and they courses dedicated to Design Patterns. Can they be all that bad? From what we've had drilled into our heads, design patterns should be used whenever possible. Remember the whole "low coupling, high cohesion" design tip? Using patterns allows for just that. We recently completed a lab that combines multiple, eight to be exact, design patterns.

Another thing I'd like to mention is that most earlier generation programmers have learned to code a certain way and refuse to change it. More companies are adopting the Personal and Team software processes (PSP and TSP) that are saving them millions of dollars a year on development. Part of those processes are doing preliminary and detailed design of your program, which includes making detailed UML diagrams.

Well, whatever...us n00bs are going to take over your jobs someday, or at least we'll end up teaching all your old folks the right way to program. IMO, your list sucks. Oh, and Java is going to take over -- slowly but surely. Peace.

for u kids out there, don't ever read a list like this without questioning the validity of it.

Wow...when you get a clue...let me know

Cory Larson, "This is a very prestigious school (4th in the nation)". I would have taken you twice as serious had you not said that. Not that the school isn't prestigious, just that if it is you don't need to be advertising it.

The problem with patterns is similar to interfaces. Why do people write them when they're only used twice?

Cory,

Wow. That post was quite inflammatory. How can you post anything that surely as a student? You don't know anything (and will be treated that way by employers) until you get out into the world and get some work experience.

You already seem very set in your ways, and you're already a student. So what will happen to you in 10 years when the industry inevitably changes and you're clinging to your old ways? There are definitely languages other than Java. Ruby is seeing quite a surge in popularity at the moment, and C will be required for a while for low level, high performance code. There's more than one language, and many of them have a specific niche or purpose that they serve. There's no one language for every purpose and every person.

20 Lines to a function? I'm more of a 1-page (2 at most) on the printer. At 20 lines, you're just making more functions for the sake of making more functions.

2 milliseconds is a looooong time... At 60fps that's 12% of your frame!

Nick

Sounds like the author himself is a bit crappy. Some of the statements are thrue, but believe me, most are NOT.

Good post. I disagree a little bit with the "multiple returns" item. Although it needed by applied religiously, functions with multiple returns can make maintenance more difficult. It can make it challenging for another developer to fix/modify the function because first they have to understand every exit condition you cooked up.

Of course, there are times when multiple returns help make the function more clear and easier to maintain. But I think most of time its better to avoid them.

this is dead f*cking on.

This list is really misleading and while some of the points are more or less true I think this list will do more harm than good.

The true sign of a bad programmer is anyone who blindly accepts any of the points on this list without looking at them in more depth and actually trying to understand when to apply them.

Functions or methods do have an optimum length, and probably this depends on the language. For example, in Smalltalk, where you have the best tools and development invented yet, you want short methods. In BASIC, however, you'd probably go insane if you did the equivalent.

In COBOL you'd go insane in either case, you are already insane if you work in C++ or Java, and you live in a hut in the mountains where you make your own tools if you work in C :)

Audrey needs to shut the fukc up.

LOL @ Corey.

4th in the nation? How come nobody has heard of them? hahahaha

Trust me, as an MIT student, I can tell you that you guys are not even in the top 15 of anything remotely engineering/cs-related. Now go to bed, the grown ups are blogging.

As far as the author's list, I can relate to a few of those things and the rest of which I can definitely laugh at. I think it's pretty neat that this programmer doesn't take himself too seriously.

You're a Crappy Programmer when you just hate the Java language.

C'mon...all your statements show that you just hate Java and OO programming.

There are a lot of other signs that shows someone is a crappy programmer.

You could change the title to "You're a Crappy OO Programmer...".

You forgot one - thinking that object-oriented programming is an answer for everything.

Don't get me wrong - OOP is good, very good - but I've seen *so* many misuses of it that sometimes I just want to cry. I started with C (yes, I am that old), I embraced OOP when C++ came and I use and write it daily. But programmers *must* know that sometimes non-OOP solution is simpler, more elegant, works better and is easier to write/debug.

Ha. You know you are a crappy programmer when you bail out. I went through 5 years of hell as a CSE at UCLA (i think it's the opposite of 4th in the nation) and found out that I hate cubicles, error handling, and that Java sucks compared to videotaping models as they frantically change clothes between runs during fashion week (aka life is good). So don't worry about this flaming noob wedding videographer taking your job.



Good post. And don't flame me too much cause I've selectively forgotten everything from 1998-2003; as far as I'm concerned UML stands for Undressed Models Lookbetterthanelegantcode. And for Cory, getting a degree in software engineering is equivalent to getting a drama major in ventriloquism.

Wow, I'd say this list is pretty good. Also, LOL @ Cory Larson, pro-student coder who thinks Java is going to take over the world. See sign number 1... ;)

People, the whole point of this article is that if you apply ANY arbitrary rule/guideline/methodology/tool/what-have-you without understanding why, you are being a crappy programmer. Don't do things because "that's the rule," do them because they will make your code better. But of course if you didn't pick that up from the article, you're a crappy programmer (and you don't know it).

Java is all you'll ever need.

This is the one that worries me as a Comp.Sci. student. While I'm not a big fan of Java, I'm a huge fan of C#. I am conflicted whether to spend my time learning half a dozen different languages well, or focusing on and mastering C#. I do have a few languages under my belt, but I tend to migrate from one to another as I find something about it I prefer. In a nutshell, Basic->PHP->Java->VB.net->C#.

Don't worry about learning a bunch of languages. If you truly understand programming concepts, you can pick up a new language in a week, maybe even a few days (great statement by an old professor when students complained about going through C++ too fast). I had to learn PHP at a job once and it took me about 3-4 days to be fairly fluent. Java is a purist attempt at portability, where other languages can provide efficiency. Assembly is at the other end of that spectrum. But if you understand both sides, you can choose the best language in between for your specific project needs. So Java is never all that you'll need, unless you can one day program the Crysis engine in a javabean...

I don't see how multiple return points are more complicated to understand/follow. They're great!

I find such tricks particularly useful when developing script-based web applications (php, perl etc). Scripted languages are never fast nor terribly efficient and so the less code there is to work through the quicker the script gets it's job done. And with 42,000,000 people viewing a given page every 12 seconds it can really make a difference.

If you have a function that has a multitude of conditions based on a fine selection of parameters, it certainly helps to identify the least amount of code required to return a value and get the hell out of that function asap.

And why are multiple return points less easy to understand?

  function bob1(param1, param2, param3)
  {
    if (param1 == param2) {
      returnvalue = 27;
    } else if (param2 == param3) {
      returnvalue = 42;
    } else {
      returnvalue = 0;
    }

    return returnvalue;

  }

  function bob2(param1, param2, param3)

  {

    if (param1 == param2) {

      return 27;

    }

    if (param2 == param3) {

      return 42;

    }

    return 0;

  }

In that example, I find the latter much more staightforward. Particularly if you're using an editor that colour-codes code. A 'return' will stand out a mile so as to make it damn clear what's happening.

And it makes code easier to evaluate when troubleshooting. If you can identify when a certain condition is true, you know that the function will, at that point, return a value. You don't have to consider the rest of the code - function returns, that's that.

With a single return point, you have to follow through the rest of the code and check that other conditions aren't changing what you expect the return value to be. This takes more time, so why do so?

By the way, let me add my own example of bad programmers. Bad programmers are those whose 'lines of comments to lines of code' ratio is less than 5:1.

5 lines of comments for one line of code might be a bit... excessive. ;)

Java, C, PHP, Perl, Ruby, Python, VB, or anything else is good. As long as you code it right, less bugs and it works, it made no different.

The most important thing is to get the job done, no-matter the language are,

sorry for bad english :)

"Multiple returns from a function work well as long as you adopt the practice of always implementing ELSE for every conditional branch and *not* using a default return at the bottom. This way, you always know what's being returned and you get the compiler to check that every code-path returns something you specified... at least this work for me in Java, C#-ish languages."

That is not true, the result of the value which can be asserted and looked at can tell you the code path that it took to get the answer in the first place. So there is an error in your logic.

Also I believe the post is a basic assertion of what knowledge needs to be passed on to programmers. Since it is a Guide and nothing more, you can take it with a grain of salt.

Each style has its own advantages, however Structure is the most inportant thing in codeing. If another person cannot read the code in a short ammount of time and know what it does. You failed as a programmer.

... if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. — EWD

While all rules are made to be broken, I generally agree with all of Damien's points. And the "all rules are made to be broken" is important subtext of what Damien's saying. There is no one perfect tool, programming language, design pattern, or magic bullet flavor-of-the-monthey enterprisey technology that is going to solve all of your problems. Programming is hard and it should make you think, and re-evaluate your tools at every step.

Some of the best advice that I've seen is that you shouldn't consider "lines of code" to be a positive thing; you should instead consider each line of code to have a "cost of ownership" in maintenance, probability of bugs, modification when the language changes, etc.

hahah @ cory... it's clear the Milwaukee School of Engineering is teaching you well... perhaps they're around #4 in producing codemonkeys..

major in computer science.. it'll be good for you

On the issue of using other languages for other tasks, eg. scripting and such, i disagree. Maybe it takes "more lines" of code, but only once if you use the opportunity to build up a library, eg. for System/scripting tasks. See my response here.

Let's just generalise. Programmers who get hung up on "unbreakable rules" (one return statement, functions no more than 30 lines, absolutely no gotos ever... etc) are generally just fretting about the details because it's easier than addressing the bigger picture.

As for Java being the only language you need, if you are only going to be good at one thing, surely Java is a good choice?! ;)

If you are CRAP, you are CRAP. You need no sign to tell you that you are a crappy programmer!!

I don't care what kind of language you use or how you go about writing it, just as long as I can read and understand your code when I have to maintain it and debug it.

Your code should be obvious and if not, at least write some comments. Even write comments out before you write the code, and leave them in there if you want to.

All these rules are great if you are starting a programming project, yet most the time you'll just be maintaining code left by others, where you extend or debug legacy code. Not sure if they teach that in college or not, yet it is the real truth. You don't start off writing new programs.

Annoying things about other people's code you figure out when you have been maintaining the same project for years :)

UML?! Java?! Patterns?! who cares, just as long as your code is easier for me to maintain.

This thread is entertaining, yet there are no absolute rules but what you learn from experience maintaining code.

Patterns are nice for communicating concepts and standards for design that can be easily understood. May also want to check out "Refactoring: Improving the Design of Existing Code" by Martin Fowler... awesome book, you'll be able to code faster with it, it'll truely make you a better programmer :)

I use multiple exits in very specific situations. These uses never seems to need to be refactored out. These all seem to me simpler than the alternative. These are my list of appropriate uses of breaks in the code flow:

1. Validation of input and immediate return for degenerative cases. This is always the first couple lines in the form "if (cond) return". The condition is always kept very simple. This multiple exit avoid wrapping an entire routine in an if block.


2. Breaking out of iteration for cases where the body of the loop discovers the ending condition, especially if the discovery does not happen at the beginning or the end of the loop. This is always in the form "do { w; x; if (cond) break; y; z; }". This multiple exit avoids strange contortions of the loop conditions and statement order. This avoids most occurences of repeating a "read" operation before the loop and again inside the loop--a situation that always gets refactored.


3. Discovering a severe, unhandleable condition that requires throwing an exception.

Hee hee! Great post - all very true. But even more, I love all the comments like, "this is wrong" or even, "I agree with all the points except for X".

C'mon people! Before spouting off, take a moment and consider that maybe, just maybe, you're feeling that prick of truth (yeah, it hurts). Rather than having a knee-jerk reaction, go away for awhile and meditate on that point you disagree with. You may find that it's your own perspective that could use a little tweaking.

Otherwise, your comments are hilarious to the rest of us: we have here an article that boils down to "if you have these views, you might suck" followed by lots of people saying, "but wait, I have that view!". Hehehehe...

Interesting post and responses. Here's a couple other additions:



You design/write applications/systems in such a way that Rube Goldberg would say, "isn't that a bit too complex?".



You don't comment your code, or the comments say exactly what the code is doing. I can figure that out by reading the code; what I'm wondering is why you thought that was a good idea.



In other words, if you're going to document, put philosophical documentation in the code; what purpose does this serve, I'll figure out what it is actually doing.

Michael McLean: I don't understand why the return is "invisible". I mean you can see it in the code. The editor emphasizes it and paints it a pretty color.

The return isn't invisible. The else clause(s) created by multiple returns is/are invisible, in the sense that they aren't distinguished in any way. Nothing about their appearance marks them as conditionally-executed, yet they are. In trivial 10-line functions, this may seem like a silly thing to worry about. When functions get longer than a single screen full of code, though, this makes things harder to comprehend for no reason.

Adam Wiggins: This can be rewritten in a clearer manner using guard clauses:

A difference of opinion, I guess. This "guard clause" paradigm is actually exactly what I had in mind when I said multiple returns don't simplify anything. They just pack more branches and conditions into fewer lines of code. It's not simplifying so much as it's disguising complexity.

I think that with proper indentation, your first example is actually clearer than your second. I also think your second version is more brittle; if you decide that foo() can handle (!y.active) as a special case after all, for example, the code falls right into place in the first version, but the second version starts to get hard to read. It's fairly likely that you'd end up just re-writing it.

Although I'll be the first to admit that with a 10-line micro-function, none of this is likely to be a problem. It's in longer functions that the problems become apparent.

CPU cycles are a precious commodity and your programming style and language reflects that belief.

Right after that I would add:

You don't care about CPU cycles at all and write something like (in terms of C) for(i=0; i<strlen(str); i++). You believe that it will work pretty damn quick anyway, compared to a database query. This is apparently wrong and under certain circumstances such kind of code may take long time, just wasting CPU cycles. That is, you are a crappy programmer if you count CPU cycles all the time, but you are total ignoramus if you don't care about algorithmical complexity. In the worst case you optimize CPU cycles, doing stupid algorithmic things at the same time.

McSeem

http://antigrain.com

I'm sure 2 milliseconds matter if you're Google.

You know those crappy programmers who don’t know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have? You don’t know any programmers like that? Come one, you know, the guys who are big on dogma but short on understanding. No, doesn’t sound familiar?

Then is the primary sign that you're a crappy programmer and don't know it:

#1 - Write a blog that shows your own shortcomings

I'm rarely guilty of anything on this list, and yet I'm still a crappy programmer. Sigh.

Fantastic list.

Of course anybody who slavishly follows these rules may also be a terrible programmer. But Damien, you pegged a number of pet peeves, things I see over and over when I visit clients. I hope this list wakes a few people up.

The one I'd add:

Every problem looks like a table. No matter what the problem, you start generating SQL to define it. Whether you're building Quicken or Word, Quake or Google, a relational database is what you'll use. You lean on the database for reliability, transactions, concurrency, and search because you can't code those yourself. Not that you'd admit it.

Your users are stupid. Really stupid.

If users weren't stupid, they would know what they need before we start writing code.

If users weren't stupid, they wouldn't need us to write programs that think for them instead of programs that make they more productive.

If users weren't stupid, we wouldn't have paychecks twice as big as theirs.

Great article. I definitely saw some of myself in there, though I like to think I've moved past some of it... I like to think that.

>"Add this one to your list:
>
>"You create dumb-ass lists of vague assertions & >present them as gospel." If -you- code like you >blog, God help the recipients of your work. Do us a >favor and get back to your game of HALO. I can't >believe this showed up as a Digg candidate."

Exactly !!! If you are writing this blog to further your career or reputation, you've done irreparable damage. Noone I know, will ever hire you.

Damien, there you go again, stirring up the pot! It's quite a giggle for me to see people who have no idea who you are or what you have done take shots at you.



I found your comments about 20 lines and the multiple return points especially funny. Those are rules that I have for myself that I break often. The real danger is when a rule of thumb becomes a rule of law.



If you have a case statement (switch) that is a series of ifs and returns that all fits on the page then it totally makes sense to have multiple returns (because its clear an obvious), but, when it turns into a complicated long routine, then maybe setting a variable then returning at the end does make sense. The crappy programmer needs a hard rule for comfort, to make the decicion for them.



I would go further in that I have different rules for myself based on what my IDE is. What does it take to make it clear sometimes depends on what level of clarity the IDE gives you, and it all boils down to what does the situation require to give clarity to the solution.

this list is 100% dead on...if you are disagreeing with it, you are the idiot on the team (or more probably the "architect") that the people that know WTF despise. why dont you do everyone a favor and just move into management? you will fit in there very nicely.

Phillip Story,

In your comment above you wrote the following:

"This kind of quote used to make me disappointed that I never went to university to do computer science. I imagined that such quotes would be thrown out by a teacher, followed by the magic word "Discuss"."

I just wanted to point out to you quickly that what you said here has nothing to do with Computer Science. I'm a college educated Computer Scientist and I can tell that I am probably the only one who has ever heard of any of these pithy little slogans because, unlike my colleagues, I actually took a Software Engineering course. Nearly all of the typical CS curriculum has little to do with programming and more to do with complexity theory, information theory, artificial intelligence, mathematics, etc.

If you want to be a good programmer or an engineer you need to look into a Software Engineering degree. If you want to be a scientist look into CS, but don't expect CS people to be good programmers. For the most part it bores true CS majors. Programming is just something we do on the side to prove our theories.

By the way, Wikipedia has a pretty good definition of Computer Science that sums up more what the area is actually about:

"Computer science is the study of the theoretical foundations of information and computation and their implementation and application in computer systems."

Sorry to go on such a long rant, and I know that historically CS is where most people went if they wanted to program. So, its not surprising to me that people think CS majors should be good developers. I do feel, however, that whenever I see this misjudgement made on what we do [Computer Scientists] that I should try my hardest to point out that it is another field of study that produces developers and engineers, CS is for those of us who are curious about the world around us.

I'll leave you with one last quote (from Prof. Bernard Chazelle, CS Princeton) that sums up CS in a line:

"CS is the new "new math,"..."

Nice one! I too recently deleted a whole load of important data. I sent round an email asking who had done it, and later discovered that it was a piece of my own nicely commented code.

Should I have modelled it in UML?

Luckily I have steeply sloping shoulders upon which no blame can ever land, so I was able to sidestep the flak by pointing out the requirement the code was meeting.

Apart from making me more streamlined as I fly, my sloping shoulders are a clear sign of my crappy programmeryness. Please add it to your list.

In some places I've worked I have felt that to err is human, but in others it is a sackable offence. Strangely, I think the more forgiving places are more productive.

Hmm,

So, from what I'm reading it sounds like the best way to be a crappy programmer would be to dogmatically ascribe to a bulleted list of do's and don'ts...

I then have to question the utility of providing help to these folk in another list of bulleted do's and don'ts...

Rather ask the Oracle at Delphi what makes a good programmer... Her answer boils down to:
Know thine coding weaknesses
and
No guideline, stricture, rule or maxim to excess.

Hey, hey, hey ... you are missing the point.

> Java is all you'll ever need -
....(BTW, this can be almost any language,....)

> "Enterprisey" isn't a punchline to you. - ....Anything that can be written, deployed or upgraded with minimal fuss is dismissed as a toy that won't "scale" for future needs....

> You are adamantly opposed to function/methods over 20 lines of code. - ....Code should not be made more complex to meet some arbitrary standard.

> "OMG! PATTERNS!" - ....But hey, your code has design patterns, and no one can take that from you.

> CPU cycles are a precious commodity and your programming style and language reflects that belief. - ....But at least you’ll be saving lots of CPU cycles... eventually.

(eventually here must be read as next year)

and so on... there is a thing called humor. learn it. it's by far the best language around.

and one more thing. i've worked with some really good programmers, and none|NONE|0 of them are dogmatic (pt. 1,3,4,5,6,11) nor "with an ego with the size of cathedral" (pt. 2,8) nor stupid (pt. 7,8,9,10,12).

that's the point..

cheers

Damien, your article is an expression of your stupidity!

While I don't subscribe to rigidly keeping functions <20 lines, I think the intent is good. I've seen a "colleague" write an entire web application in one function. >1000 lines if I remember correctly. An absolute pig to fix.

Sometimes companies use lines of code as performance indicators. In this situation, copy and paste are your friends. If you get a $5000 pay rise because you've created extremely verbose code which is slow to run and painful to read, would you write beautiful, tight, fast and easy to read code and forgo the pay rise???

Another sign that You're a Crappy Programmer:

After reading this article, you feel deeply offended. You cannot resist the urge to leave a comment here with attempt to prove that you are not that crappy.

(you see, I am fine with it... I do try to write only 1 return, 1 page method, and ... seems to be nothing else )

As a programmer, this is good stuff. I have been programming for a good long time, and have made more than my fair share of mistakes.


Those of you who don't understand that this list isn't "what not to do", but rather "learn what to do and when" should really spend more time in school.


I, personally, have broken every single one of these "rules", with the exception of Java. I don't care much for Java. ;) There is always a time and a place for following these guidelines and for breaking them. A good programmer knows when to do both. A crappy programmer simply follows one set of rules without knowing the underlying reasons for using them.


And to Corey over at MSOE. I live in the Milwaukee area. You are seriously a disgrace to your future profession if you are this closed-minded. Hopefully, your comments were in jest, but if they weren't, then I hope one of your professors cracks open that thick skull of yours.


Good luck to all the programmers who read this. I am currently on sabbatical from "real" software development and living in XHTML bliss :P

Another: Those who write database joins & filters in code because they think it will be faster

You haven't met some of my users. Wow... it's amazing how bad they are and it's actually not with the application I work on it's with Windows. They lack basic knowledge of the file system (or should I say they don't fully grasp where files go when they download them. If they aren't in the "My Documents" folder where could they be?). Anyway.. good article. I'm definitly a crappy programmer by your definition, I do have stupid users and I don't like methods with multiple return points. But I think that's more of a style thing. You like it or you don't.

I'm not blaming you guys opposing Damien's arguments.
You have to have experience (not some but a lot) to understand the list.

In my understanding, the three known levels of expertise can be defined (amongst others) as:
- Junior: coding according to the specs
- Medium: coding for himself
- Senior: coding for the user

As for the user, I believe the adjective term is simply wrong. He is not supposed to be something, a user or an idiot or whatever you might call him, just because he works with our system. He is the person that uses the system to do his job.

All good points, but you one important point:

Featuritis.

You know the drill: "Hmm, I bet I could add this feature... That would be fun!" Coder implements feature. Later, coder shows feature to management and it goes like this:

"Hey boss, look at this nifty feature I added!"

Coder shows feature to boss

Boss replies, "Wow, that's pretty cool... Um, when would I want to use this again?"

Coder replies, "Well, you can do so and so with it, see?"

Boss replies, "Okay, I see that, but still... Why would I ever need it. I mean..."

Boss shrugs shoulders.

Coder, "Uhhhhhhhhhhhhh... Is that the fire alarm?" Coder makes quick exit

In other words, wasting time implementing useless features just adds unnecessary code to maintain and confuse users.

Which reminds me, I do like a twist on the users are idiots philosophy: during the development process, I always like to assume the users will be idiots. This way, I always search for ways to make usage of my application as foolproof as possible.

As to a couple of the people who posted replies:

One poster stated that he codes device drivers in C and that the author did not know what he was talking about. Here is yet another classic case of a person who considers himself a programmer just because he can do one simple task with a programming language. I myself have written device drivers in C, and it's about as difficult as writing a "Hello World!" program. For those who've never done this, you're basically doing nothing more than creating a wrapper around instructions the hardware expects which conforms to a well defined API the OS expects device drivers to conform to. Contrived example:

void * read( int bytes )

{

void * data = kmalloc( bytes );

mydevice_init_dma_transfer_in( data, bytes );

return data;

}

Whoopee!! If I can figure out how to do that, then I mus t be a good programmer, right? C'mon.

Then there's the poster to was on the right track by boiling down a previous poster's code to:

return ((x && x.active) && (y && y.active)) ? x.calcval + y.calcval : 0;

Nice, but you stopped too soon. Look carefully at it. How can this be made more readable?

return ( x && x.active && y && y.active ) ? x.calcval + y.calcval : 0;

If you know how expressions are evaluated by the compiler, then you know they're evaluated right to left, and the evaluation (in a case such as this) stops as soon as the first false value is encountered. Hence, the extra parenthesis were unnecessary.

This still doesn't change the fact that there are still cases where multiple points of return make sense. This is especially true in embedded systems where RAM and registers are precious commodities, and allocating space just to maintain some single point of return notion can be a terrible waste of a precious commodity. Don't believe me? Try developing for an embedded micro which has 256 BYTES, not KB, not MB, BYTES of RAM, and all of 2 KB, read, kilobytes, of EEPROM. I'd love to see you try to convince someone who's developing firmware with these constraints that they must maintain a single point of exit. Seriously, I'd love to see it. I enjoy a good laugh.

Way to go dude :)

Some guy said it all - it's humor, but if instead you're deeply offended, you *are* a crappy person *and* a crappy programmer

Cool article :D Seen quite a lot of these stuff.

Anyway, it's always good to remember how crappy we all can be, some of us used to be, and some still are ... :D

This article is a paraphrase of "Everything in moderation". I think that this kind of statement is not normally attributed to engineering.

I think that the best point to make is the importance of Consistency in programmatic style for a particular project.

I don't like multiple returns. I think there should be one or two return points. Two return points is OK so long as the first one just tests the validity of the arguments (sanity checking) and the test occurs immediately at the start of the method body, before any local variables are declared or methods are called. Multiple return points definitely messes things up for method of more than 20 lines!

Regarding 20 line methods, it really depends on the context. Sometimes a particular language encourages you to be hyper-compact in terms of pressing the Enter key. Other languages are verbose, and like the Enter key.

There's always a place for scripting languages. It's best to make a choice up-front of a set of two or three languages in total for a certain software company or project, choosing one for each programming paradigm (Procedural/O-O, Scripting/Interpreted, Software Build and Assembly, Database, Functional, ...).

I'm always fascinated by responses to articles like this - and it IS a good article, BTW. I love Java as a language, but I certainly wouldn't ever go so far as saying it was the only language needed - and for those who weren't paying attention, notice Damien qualified it saying that he used Java because it is the most afflicted (although I think C# follows a close second these days). And, Stoyan, you are so right.
Anyone who says one language is SOOOO much better than another doesn't understand the difference between programming languages and development tools. All languages have a niche and every niche can have many languages. It's usually the tools people fall in love with and then by association the language.
There are ONLY guidelines NOT rules. I've known people who'd like to believe differently, but even a couple of them admitted it's because they didn't want to have to THINK. The truest test of good programming is a) realizing that for every set of guidelines there is an equal but opposite set of guidelines available, b) knowing when to use certain guidelines and when NOT to, and c) realizing that no matter what you use, all code increases the entropy of the universe :)
One last item of contention: if you can't intelligently respond to articles like this, if you can't believe that there is a measure of truth to what was said, if articles like this hurt your poor, little, fragile feelings, or burst your idealistic bubble, or invade your comfortable self-contained world, then it's probably because you don't have the confidence in your own skills as a programmer to actually try something different or at least realize you DON'T have all the answers.
ALL of us have created code that someone else will think is crappy, the sign of a good programmer is accepting this, but still trying to make it as easy as possible for other programmers - good or not, experienced or not - to understand our code.

You are a boob.

Here is a sign you are a crappy programmer. Java is all you need when the company you work for expects it. You think Rails will ever overtake Java or .NET. I am a believer in efficient development practices like the next guy but everything has its place. It annoys me that people jump on the bandwagon when the next new hype comes along. First it was Java, then .NET, then XML/SOA, now Rails. When will you idiots ever learn. Rails will be exposed sooner or later and you same clowns will be ranting about how bad it is. Maybe it is not the language or the methodology. Maybe it is just you.

>>You model all your code in UML before you write it.

One of my favorite quotes that I have ever read was by Philip Chu:
"This is not to say that design is unnecessary. But after a certain point, design is just speculation."

Well you are one crappy Article writer,
this stuff is really unecessary as programing
and software depends on more than just rules.

David Jenkins has hit the nail on the head folks - I suggest that you malcontents just grow up...

(nose held high ... chest puffed out ... head deeply embeded in a deep dark crevice) Well ... phffff ... it's obvious that the author doesn't understand object oriented programing or highly reusable, scalable, enterprise frameworks that allow you to develop software with the wave of a mouse ...



(now back to reality)



especially, when that reusable, scalable, enterprise framework, requires 10 time the effort to accomplish the same task but most people are to caught up in the hype to see that or enjoy bending over for the people pushing this garbage.



I can relate to a lot of what was written through my encounters with idiots, mindless lemmings and parrots who use buzz words, hyped up terminology for mindless things, or patterns to make themselves sound intelligent because they lack the intellegence, common sense or were born without an ounce of creatitivity to develop something that anyone with a brain can come up with in 5 seconds.



We're all crappy programmers. There's always a better way to do something.

wouldn't it be great to pick out the people you like on the internet and work with them without organisational structure.

i'd never want to meet, let alone work with a buzzword parroting lemming.

ofcourse there is the offhand chance of running a retardathon now and then, which is quite normal on the internet. just like what can be read in all these comments....

reference:

http://www.penny-arcade.com/images/2004/20040319l.jpg

This list is a joke, mostly; while there may be a few good, general rules that most agree on when it comes to software engineering, what *really* matters most is that everyone on a development team agrees on and adheres to the same rules, thus ensuring consistency. I don't think anyone would disagree that consistency in code is more important than following anyone's specific idea on just what is "good" and what is "bad".

CPU cycles are a precious commodity and your programming style and language reflects that belief.

Another sign: you anonymously insult the author of this article but fail to justify your view with any useful comments.

Lets talk about UML and design.

1) UML's shite at getting down to enough detail to code. UML is still being developed but as I see it, it has two choices, don't bother or get complex.

2) Performing design at the code level is soooo dumb, it the hardest place to change a design. And for all good intentions your code is never going to be easy to follow only ever by you, never another developer.

3) There isn't a methodology out there that can get us from business requirement to detailed code, plenty are trying no one won.

4) No Agile development isn't the answer. That just makes developers talk to people that aren't developers.

5) Don't under estimate charts, a picture really can be the same as a thousand lines of code. And I know which I would rather see.

6) Architects translate business requirement to detail enough to code, developers on the whole suck at this.

7) Developer really are mostly jocks but without the muscles! They like to give everyone else mental wedges.

Some of these "rules" and their exact opposites are just corrolaries to the rule that comes out of this statement from Albert Einstein - someone who managed to stump most of us with his concepts and thoughts:" I like everything to be as simple as possible - but no simpler."

So, if it takes +- 300 lines to code, don't spread it across 10 functions unless that makes it simpler to understand and maintain.

If it is more straightforward to have many return points than to converge onto one, go for it - but if you need to code the same five lines of cleanup code before every return statement, you blew it.

The trick is to know the best way to do "it" before you're done. If you didn't, then at least be honest to yourself, code it again and throw out the first attempt.

And as another correlary to the above quote from A.E. - there is such a thing as the correct amount of code for a solution - less is bad, but so is more.

I wonder why so many people think they know better when clearly they don't?

Let's try to remember on the odd occasion that this whole "stuff" with the computers was meant to make our lives easier - not harder and, heaven forbid, it wasn't meant to replace them, either.

So, for those of you who take all of this too seriously - I don't care if you are crappy programmers or brilliant ones, you're far too hard to work with ...

I hope that you guys don't think that crappy coding is a new phenomenon. Change the names of the languages and you could have written the same things about ALC, PL1, FORTRAN and COBOL thirty years ago.

POST is WROOOOONG!!!!!!!

I'm not Crappy Programmer. :-P

Hey Cory from MOE:

You sound like the Ryan Leaf of programming...

Oops, MSOE... ;~)

and that.. i'm proffesion, and my code perfect

you are all juniors

adios muchachos!

LOL I can bet that your code is far from perfect.

And btw, practice made it perfect, so if you're crappy programmer, you can always improve it

Cory, your school isn't even in the top 400. I was curious so I actually checked it out. It isn't at the top of any list. Princeton Review gives your school the lowest possible selectivity rating. Please try to get a grip on reality. Go back to your farm where you belong.

Cory broke his website and can't figure out how to fix it. Maybe someone can help him. http://people.msoe.edu/~larsonc/

I just read 1/3 of what you wrote.... OMG, the world depends on us! Run for you lives!! ;)

Ps. No wonder why most of the best SW innovations failed and we went from CORBA to WS!

Guys, I think some of you are missing the point of this post (as far as I can tell).

HUMOUR.

2 Noi Nham:
I have source code of win2k. and most part I coded

The advice against using multiple return points has been passed down for years, and almost certainly derives from C programmers who would have released resources at the end of a function. If another developer came along and inserted a return statement before the resource was freed, then leakage would occur.

In modern languages with exceptions, a function can be exited at any time, and so any decent programmer will use auto pointers or finally blocks to ensure resource release under any circumstances. In this case, we can put return statements anywhere, since they are no more damaging than exceptions and much easier to spot.

How is the whole "over design in UML" issue any different than the "over design in (currently favored design technique)" issue that has existed since computer science was invented.

When I was at Michigan State, in 1985, I had two major overdesign lessons.

The first was a intro-to-programming class where our textbook expounded on the values of MPL (Model Programming Language) as a design technique. The idea? You write your entire program, by hand, using this standardized pseudocode (just writing it in the PASCAL we would eventually be using resulted in an 0 for the assignment.) This was "good design."

The second was when I was a TA a few years later, and one of the "best practices" shown to students was a company who spent 2 years doing a detailed flowchart of a project, and 2 weeks actually coding the project.

That the new design technique is graphic and has the Rational big-hitters behind it doesn't make it any worse, when it's over-utilized.

LOL yeah i've been guilty of more than a few of these rules heheh, fortunately i learned from them. Thanks for the smile this morning

No need to write an entire UML document to add a simple function to existing code. IMO it only makes sense to use UML for a ground-up project or a major enhancement.

Design and Structural Patterns tell how to structure your code to aid maintainability and safety. Maintainability patterns help us write the code so it can be easily changed as the problem it solves evolves. Safety patterns help us prevent errors.

I agree with much of the article only for the reason that I believe people should be more concerned with the practical aspects of programming, rather than being hung up on whether they're using the right patterns, etc. Though I believe it makes good practice to try out different methods of programming.



Anyway, the thing on the list I most agree with is "Your users are stupid. Really stupid." I wouldn't say it in such a condescending way myself, but I think the most important thing that many programmers neglect is anticipating things that any user can do by accident. Just like you can't build a toy out of Legos and expect it not to break if it's dropped, you can't build a program and neglect to deal with possible misuses.



The worst thing that could happen is that people could possibly find ways to exploit your program, but even the little things count. For example, I use a program at work where you have to enter a number in the format "AB-12345", etc. to find a record. If you forget the dash, the program won't find the record. That is bad programming, in my opinion. Any idiot can foresee somebody forgetting the dash and come up with a simple solution for that (especially being that this program has been released many years ago). But, at least they allow lowercase (ab-12345).

Design patterns are good for changing your mindset. I know many patterns but don't care to know them all. The point is to understand their use and come up with a design that fits your needs.
As for the small functions thing I strongly disagree. My practice is to make a function do exactly one thing if there is another "function" to the function I put it in another function that is named such that you know exactly what it does by the name. Since the function is so small (usually between 5-8 lines) there is less chance for error, I never have to cut and paste, and many of those functions/Methods never have to be looked at. So when you're stepping through one of my programs you read it like English and you only have to look at relevant code. If there is an error in one of the functions its easy to spot. It makes maintenance easy. 10 lines isn’t a rule I follow; it just happens when I’m not being a lazy programmer. Also, if you’re cut and pasting code in C# or Java either your tools suck or you’re lazy.

CPU cycles are a precious commodity and your programming style and language reflects that belief.

So non-crappy programmers don't waste time worrying about CPU time, right? Is that why non-crappy programmers scatter (and I mean scatter) blocks of code like this around their applications?

strcpy(numberString, token);
strrev(numberString); /* reverse the string in-place */
while (strlen(numberString) 

The following is what the programmer really meant to say. It takes a tiny fraction of the time that the above code took, and it's safer code, to boot:

sprintf(numberString, "%0*.*s", NUM_MAXLEN, NUM_MAXLEN, token);

This change significantly sped up the application that the non-crappy programmer originally wrote. I'm glad that crappy programmers like me actually worry about CPU cycles.

I guess crappy programmers like me have a hard time posting to blogs. Here's the original code block:

   strcpy(numberString, token);
   strrev(numberString); /* reverse the string in-place */
   while (strlen(numberString) < NUM_MAXLEN)
   {
     strcat(numberString, "0");
   }
   strrev(numberString);

Apologies.

PMP

When hiring a programmer, all I care about is that they understand and respect prioritization and can deliver code on time and fix bugs quickly.

If a programmer I'm interviewing starts getting tangental about his religious software engineering beliefs I sour quickly.

I read this post with pure glee. We have a guy on or .NET team who came from Java, and he fits this decription precisely. He is all mouth and no action. The phrase "most of the real work in your office is getting done by people sending around Excel spreadsheets as they wait for your grand enterprise visions to be built" sums him up to a tee. He spends much of his time complaining to anyone who will listen about how unprofessional the rest of us are, while all the time producing nothing of significance. Needless to say, the CEO loves him.

signs you are a self-important blogger, you write a top ten list of any kind.

This is great; I suck!

Leave Java to Java people.

@boring -

Is that the most constructive thing you have to say? I do not see Damien's post as being self-important. He was offering his perspective on what he has experienced and put it out there for discussion, a very valid discussion.

If he was self-important, you would not see him at a conference like Lotusphere, sitting in the lobby of the hotel with another gee at 1 in the morning, just talking the night away, while everyone else is partying away in the karaoke bar.

Perhaps you should get to know a person before making such a comment. At least he has the backbone to put his name on his post!

Not to say that Damien has never had any self-important moments in his life:-)

Signs you don't have a sense of hummer.
You write hate comments.

Signs you have too big of an ego.
You write hate comments when someone talks about some thing you do in a negative way.

Signs your a D*#k.
You’re reading this and getting mad.

"Signs your a D*#k."



Are you calling me a duck?

My particular flavor of bad design practice is codified in the "Design Pattern Facade Pattern":

http://www.jroller.com/page/landers?entry=the_design_pattern_facade_pattern

java, whats wrong with only using java? no really! no worries, im just kidding, C++ solves everything anyway. god i need to go back to school!

My goodness but we're all just a little bit serious. I found this post from CNET, and it was an amusing bit of fluff. I don't think for a moment that it was intended as anything more than that. So everyone laugh and breath deep and stop being so personally wounded about a bit of goofiness, lest one leave the impression that programmers are sorely lacking in a sense of humor. After all, bitterness and woeful jerimads are very unappealing.

Multiple returns are not always bad, but they are a sign you should look closely, and make sure this should not be more than one function.



As for function length, I think there is some truth in this, not in the length of the code, but in the functionality expressed. Often once the reuseable bits are split up, all that is left is 20 line functions.



The real thing is that following the rules every time leads to nothing but the same stuff over and over. Really, the rules should be considered guidelines, and are good indicators that you need to take another look at your code to make sure it is reall what you wanted to do, and that it is readable.



BTW, you can do this even in COBOL. Even old COBOL can be clean, modular, and readable. I work in COBOL, Java, Ruby, PERL, C, and even VB. They can all be done in clean and readable ways, just some lend themselves to it better than others. Ruby is the BOMB!

For those who are interested in viewing a list of every DVD that Cory Larson owns...

http://people.msoe.edu/~larsonc/dvds/

You can sort them by name, duration, or rating! I suppose this way he doesn't have to leave his computer to decide which movie he wants to wank off to.

...must be a Milwaukee thing.

Damien, see what you've started? Many of the above ^^ didn't recognize the joke!

I am proud to say none of that applies to me. At least it doesn't now... but yeah, I probably did or believed in everything on that list at one point or another. What I'm saying is, I'm comfortable enough with my skill level to say yeah, I'm a crappy programmer, and even though I've learned from those mistakes and gotten better, I'm still crappy. Why? Because I have a lot to learn, just like every last single person in this business. And I make mistakes and I believe things that I'll probably think are incredibly dumb later on. It's just the way things are. Remember this kids: If you think you're amazing (or if you're offended by this) then you're likely one of the worst offenders.

As for the people who are whining that you're wrong and so on and just generally throwing out insults that are embarassing to 9 year olds, I have this to say: The truth hurts doesn't it? Face it, you're shitty, and you can't handle the truth. Get over it. Better yet, learn something and stop polluting the job market (yes, I'm sure your degree from DeVry makes you awesome, blah blah blah).

I don't aggree with this "the process doesn't matter as long as it get's done" attitude. This discounts the importance of maintainable code. I can't count how many times a maintenance project was delayed because the original code was a designed at code-time (i.e. hacked).

Damien - classic post.

Guys. The best quote here is: "getting a degree in software engineering is equivalent to getting a drama major in ventriloquism".

(Speaking as a person who has a degree (or is it half a degree?) in computer science, etc, etc).

Perhaps ego-less programming is the future ? Mind you, it wouldnt have provoked such a funny outcry from such a bunch of insecure hacks...

:-)

---* Bill

One that I particularly identify with is the error handling (I do follow up on generated errors - largely due to remembering this incident.)

Back in my college days, I studied Computer Science at the University of Waterloo - along side Berkeley and MIT, it was considered one of the best places in North America for anything computer connected at that time. A class had an assignment to write a program in Pascal to find the x intercept of a quadratic function. They discovered a bug in the Pascal interpreter - it did not create an error to take a square root of a negative number. The square root of -4 was returned as -2 (Whoops!)

I went on a work term to the company that actually wrote that Pascal interpreter, and got to see the bug fix. The programming house was the source of interpreters for BASIC, Pascal, Fortran, Cobol (aka paint dryer) and APL and to save re-inventing the wheel, used various common components.

Back in those days, no desktop systems had floating point processing in hardware, it was all through software. It tried to be as fast as possible, written as assembly code on each platform, it took the source values, crunched the basic math, and returned to the parent code. Everything was assumed to be screened to be valid - no error checking in the floating point code.

Well, the Pascal interpreter coders assumed that all of these common components did full error checking - ensuring minimised code repetition. If you know how floating point numbers were typically laid out in these packages, the first byte contained the sign of the number as bit 7, bit 6 as the sign of the exponent, six remaining bits as the exponent, and the remaining three to seven bytes as the mantissa (depending on the precision of the floating point support.) The logarithmic function (used to do square roots) ignored the first two bits of the first byte as they would not change, and processed all of the rest. Hence, the square root of -4 became -2.

The fix - check the error situations both in the interpreter before the call, and in the floating point code before processing. Makes sense in retrospect, but in those days, 64 KB was a big and expensive system - with a hard drive, that was equivalent to the price of a car. Add in that the processors of those days ran at about 1/4 % of the speed of today's desktops, optimisation happened as you coded.

If your math is failing you, the square root of -4 should be 2i, not -2.

Thanks for the laugh.

Long complicated, highly indented, uncommented functions with multiple returns promotes job security...

Good list. I was surprised that I agreed with so many, but I figure I'm still a crappy programmer. I just work for myself so nobody else ever has to know.

In reading this list and the comments, I get the feeling that a truly "crappy" programmer is one who refuses to budge on an issue or issues. Whether it be which language is the best, the maximum allowable lines in a function, or whether or not UML is a good design notation, obstinance is rarely if ever a good policy.

So, IMHO, a good programmer is one with an open mind. A crappy programmer is narrow minded.

There is no best language. There are infinite number of correct solutions.
New languages will come and the old ones will be forgotten.
Use the one that best suits you and code in your own way. When you finish, try to improve your solution. After that, try to improve it more. Repeat many times.

Finally, publish it open source. That will push it closer to the best solution.

Hoo boy, I loved this. Hidden in the arbitrary criticism are some real gems about better software development.

I DO usually make a passing attempt to make a single return point in functions, but never if it requires painful logic arrangment. I like being able to set single breakpoints/asserts/traces at the end.

Ben, if your code were crappy, your customers would know. So far, your code hasn't crapped out on me ;-) Neither has Damien's despite my best efforts to abuse @*

Damien, I can't wait to crap-test couchDB.

Signs you're a blinkered weblogger: You think that everyone who doesn't agree with your personal philosophy is a fool.

With regard to Damien Katz article. I believe every programmer should spend about 5 years writing time critical embedded code on small processors (8051, Z180, etc.) before even touching a compiler on a PC.

Doing this will cure any programmer of most of what's on your list (except possibly over-optimizing code, embedded code almost always needs to be carefully optimized just to fit).

Heck, for some architectures (such as the PIC family), writing in C isn't even viable. The processor does not have enough resources to support it (PIC16C52 has 512 instruction words, 32 registers, a 2 level stack, and no RAM !). On devices like this, you can forget about Java.

My favorite sign:
Your 20 years experience are really 2 years, repeated 10 times.

Summary: Everything in software involves tradoffs, and no one tool is appropriate for all tasks. Crappy programmers don't understand that. Oh, and bugs are bad.

a.k.a "If all you have is a hammer, everything will look like a nail."

(Did I miss anything from the original post?)

re: Function Length

Actually, there is hard empirical data that shows that short routines are not necessarily better, and indeed can be worse, than longer ones.   See "5.5 How Long Can a Routing Be?" in Code Complete by Steve McConnell, but here are a few studies referenced in that book:

• An empirical study of 450 routines found that small routines (those with fewer than 143 source statements, including comments) had 23 percent more errors per line of code than larger routines.
• A study by Basili and Perricone found that routine size was inversely correlated with errors; as the size of routines increased (up to 200 lines of code) the number of errors per line of code decreased (1984).

Like most things to do with programming, there are no hard and fast rules.   If a function exhibits good cohesion, of the right type, then it should be whatever length it needs to be.   Arbitrarily breaking it up for no reason other than to achieve some notionally ideal line count is, well, just dumb.

Just my $0.02 worth...

From a pragmatic point of view, Java, UML and design patterns are a good thing for the SW industry. Imagine we would all write in Ruby and Python, then the world would be a nightmare: much less programmers needed, much less bugs, much less code to maintain, much less books and tutorials to sell. I believe for these reasons that Java is the best thing that ever happened to this industry.
Alain

Good post. You forgot "Comments the obvious" or rather what is happening rather than WHY it is happening...

i++; // increment i by 1

NO! NEVER!?... :-)

Most of the list you have are tenets of "agile methodologies".

Nice article, i like your style of thinking : a good coder has to know the 'good coding rules and practices' but he must apply them in a useful way !
My definition of this "methodology" relies in only two words : knowledge and pragmatism.

New Frameworks - a method of wrapping Science (ie. new propositions awaiting validation) in terms of Engineering (where robust scientific artefacts can be reasonably adopted in a mass market).

This entire discussion just goes to show how hard it is to identify programming talent in terms of work output. I know people who I consider to be very good coders but with bad habits, and likewise people accuse me of having dense code, but still call me an excellent programmer.

I think looking at it from a personality and traits basis is easier. A good programmer tends to have:

I think quality of work is a consequence of these attitudes, not any specific practice (although some specific practices are more likely than others with these mindsets).

Dead on.

Developers need to remember that software is developed for users, and as Joel Spolsky likes to point out, the only real purpose of commercial software development is to turn a profit. If you're wasting time thinking about how to implement a design pattern, or how to re-engineer all of your already-working code so that you can adhere to some guideline you read on the net somewhere, you're probably no longer in sync with the goals of commercial software development.

Basic functionality and maintainability are the most important issues for software developers to consider the majority of the time. That clever algorithm you spent 10 business days implementing that shaves a few milliseconds off of 10% of the requests that hit the system? Great job! It will NEVER be seen by the end-user, and could waste many hours (and, therefore, dollars) of the company's time next time some other developer comes along to fix a bug or add a feature to the same code path.

If you develop real time systems and the like, please spend your days optimizing away. But the majority of developers reading this are writing software for the web and are wasting lots of their companies' time and money worrying about issues that will never have much of an impact on the software they write.

And, finally: Keep it simple, stupid!

I see no problem in using 4 lines of comments to describe one line of code...... provided that your 4 lines of comments actually helps the poor smuch who is stuck with fixing the bug that your one line of crappy code has created in the first place.

Wow all this time everyone has spent blogging about this, you could have written your own version of and Taken on , as well as learn what not to do on the way..

Im going to stop wasting time and actually write some code, surely pratice makes perfect..

Chill out everyone and stop wasting time watching TV and blogging about such insignificant crap. Talk about something that is more constructive and put your efforts into helping others, or at least constructive criticism..

Everyone is entitled to their view, if you havent learnt to sort the wheat from the chaff then you have some way yet to come..

Damien, seems you forgot a couple one MAJOR sign that you're a crappy programmer, namely:

You're too clueless or too damn serious to see why this list is funny.

This behavior can just as easily be observed by watching TV shows like "American Idol" or "So You Think You Can Dance". You see these no-talent clowns get on stage and give a painfully embarrassing and utterly terrible performance. Then, when not selected by the judges to continue, they act shocked and insist that they are clearly super-star material.



Same thing with some really bad coders, waving their misinformed philosophies in the face of measurable results to the contrary, and always backed up with a self-confidence so overbearing that it can only stem from maintaining a tightly closed mind.



What's worse is when there are companies that seem to make a point of hiring these types of people because the hiring manager is even less informed, and thinks that each of these people he/she hires is a prophet of software design.

i++; // !!?!?!
People, the post-increment operator must create a copy of the original, increment the original and return the copy.

++i; // simply increments the original and returns

You have this in a double-nested for loop (matrices) then you are accumulating those 2 milliseconds.

best of all those mindspraying comments (from the digg-link somewhere up here):
I realized I was a crappy programmer when I compiled and got the message, "Error: Too many errors."

now beat it.

Ah, I definitely have to put up with object-fascists who frankly write 10 times the amount of code that they need to, and imagine they are more intelligent for doing it. Bunch of w*nkers.

I don't get what you want to say about all that java. I don't think so that there will be a programmar who can live by stucking only to Java. if you see in detail there are lot of more technologies (struts, ajax, ... other web designing things) which are must needed to be a java person.

Moreover, what i believe is that a person can not be a very good java progarmmar unless he is good at C/C++. So how can you say this thing particularly to a java programmar.

sounds like you write a lot of 'hello world' programs.

On the CPU Cycles note: I recently had a batch app canceled because some CP did a bad bubble sort of a 1000 entry table. Took 3 minutes CPU time on a IBM z/990 with 450mips cpus. I took the simple out of invoking a utility sort that took less than 1 second. So ignoring CPU cycles can be very expensive. It's relative. In both senses.

On the OOP thing, we tried to install a new C++ app but it could not run in a realtime authorization environment. We needed 50+ TPS on 1 of those 450mips cpus. The app could only do 7-10TPS. Contract cancelled. Cost $1,000,000+ and 18 months. Now we do 100-200 TPS on 1/4-1/3 of 1 CPU in one of those 'legacy' languages with inhouse developement.

As a freaky CS person, I read tomes unendingly in pursuit of no end. I am American, see? As I read a book (the book) by Stroustrup, our old friend from the mid-90's, father of C++, I noticed him saying some silly things about programming styles - what is clean and what is messy. He definitely got a lot "right", but I fear he teaches his students some things that I feel are very dirty indeed. I find that one's ability to write comprehensive code relies on one's understanding of the problem and the tools at hand. He goes on to mention the old: "while (*p++ = *q++);" : The old c-string copy of ancient times that every system I have ever met has replaced with an assembler library routine. He starts out by saying this may appear ugly to the unexperienced, but then shows that to the experienced, this code is perfect for a programmer fluent in C/C++. Also, consider a modern programming situation thanks to the over-use of exceptions: you want to initialize a variable, but to do so you need to have the initialization inside the try-block. But then you don't want that try block wrapped around everything. So you declare the variable outside and assign it later inside the block. Oops, your exception might be thrown and your variable is invalid, but you go and use it anyway! There goes your code! Languages like C# utilize something called a using block to handle this. See? Tools/language mechanisms define the standard of what is right and wrong. Another example: people swear switch statements are evil! Their first argument: they are ugly. The defendant: they are elegant. They are error prone! They can result in optimized code. They blew up a space shuttle! Give me a break, give me a break, break me off a piece of that charred astronaut. It goes on... Finally, consider Knuth: possibly the most influential CS/Math cronie of all time! I personally cannot understand the man; I mean to, but I just can't. Knuth is in an alternate reality! You have to be a Math genious just to get anything out of his materials. As a cs who has taken a few upper-level math courses, I can honestly say it is my opinion that mathematicians purposely create some "field" of illusion ("quaternian") to trick the weaker minds. They tell us about multiplication and addition, but forget to mention it only works on a limited number of things. They are mad scientists!!! In reality, they are super-beings from another planet that are trying to see if they can trick us by leaving out grave details about things. Plato and Socrates were in with the whole deal, inventing "logic". Philosophers and mathematicians ... they scare me. Oh no! They are coming for me. They want me to join their forces. What do I do? ... ... ... Later suckers!

I read this article to see if I was a shitty pro0grammer. I do not consider myself a programmer since I primarily work with scripting languages like PHP and Javascript, but we all know the similarities .

Personally my favorite

"Your users are stupid. Really stupid.
You can't believe how stupid they are, they constantly forget how to do simplest things and often make dumb mistakes with your applications. You never consider maybe it's your application that’s stupid because you're incapable of writing decent software."

I live by the mantra that if users cannot figure out how to use a program or are always asking me how to perform a task in my system then obviously I have designed it improperly. Then I will take the approrpiate steps to correct this.

I recently took a $15k hit on a project, rewriting the entire thing because the client was absolutely confused by the application. I discovered two things by doing this:

Scoping a project with the client screen by screen feature by feature is important.

Sometimes scrapping code can prove to be a huge benefit to your end result as it gets you to rethink many things about the way you did things in the previous version.