Fog Creek Software
Discussion Board

Good Code / Bad Code... Bleh

Just some rambling about the good code/ bad code thing.

I’ve come to the conclusion that good code and bad code do not exist.  All code is understandable to someone at some point in time.  Usually the original programmer understands their code for a short while after it has been written and depending on how long they work with the code they will memorize an understanding of it but that will also eventually be forgotten once they have moved on. 

At the moment in time code is written there are many variables contributing to its quality.  The education level of the coder, the experience level of the coder, the experience level of the coder relating to the subject matter they are coding, the attitude of the coder, the coder’s work environment, the coder’s health, the coder’s general well being, the coder’s background, the coder’s mental state, the coder’s priorities, the coder’s understanding of the problem domain, the coder’s knowledge of the tools they work with, the coder’s intent, the coder’s habits, the coder’s pride, the coder’s goals and so on…  There are too many variables contributing to the programmer writing the code at any given point in time in order for it to be deemed good or bad. 

The code obviously holds some value to the coder who wrote it because people normally don’t do things of no value to them.  The code must accomplish something that had not been accomplished before or it must help the coder externally to the program (boost their self esteem).  It must be a step forward for them.  That is the key.  It is a step forward for them. That code conforms to their priorities, their understanding of what they want done and how they want it done. Who knows, it might be that they wrote it because their manager was looking over their shoulder (an external force), coding is just a job to them (an external force) or they wanted to learn how to do something (an internal force) or they were actually coding something (the “real” reason to write production code). 

Our position is not to ask why.  For any another person the same code may look to be a big mess and accomplish nothing.  The lesson here is twofold.  Lesson one is that all code reflects the state (not necessarily the knowledge but it’s a big part) of the programmer at the point in time that they wrote the code.  Lesson two is that in the eyes of the original programmer the code accomplished what they needed it to at that point in time.  Perhaps another lesson is that we all are or were at one time ‘that programmer.’

Get over yourself.  This is a huge step in dealing with other people’s code.  If we can admit that we are no better than the person writing the code then we put ourselves at the same level and we become better able to understand them and their code. 

You must know and understand the original programmer in order to understand the why’s and how’s of their code.  Unfortunately this is not always possible.  Try to contact them or ask about them and see what you can learn.

We’ve all heard of the guys with no experience or education that code a nice program and make millions.  Code doesn’t have to be pretty to sell.  It doesn’t have to follow every rule in Code Complete.  It doesn’t have to use design patterns.  It simply has to work and at least one person has to understand it (or several people have to understand portions of it).

So what do I do when I’m in the situation where I am not satisfied with the code base and the people maintaining it and I don’t want to work on it or deal with it any more?  Well you quit if you are able or stay aboard with a smile and try to change things while looking for a new position.  You never know.  It is possible to win people over to your way of thinking but if you can’t, don’t make a big deal out things, don’t start a fight or make a ruckus just politely excuse yourself.

In summary, there is a direct relationship between people and their code.  Not all people are compatible with all code and not all code is compatible with all people.  The quality of the code is in the eyes of the beholder.  If you are the person who created the code you will more than likely think highly of it and understand it.  If you aren’t that person then you need to either educate yourself in order to understand it or, more than likely, you need to spend a lot of time studying and refactoring it if possible.  Of course having some humility and accepting the fact that not everyone is as great as you doesn’t hurt either.

Wednesday, March 24, 2004

That's pretty wishy-washy.  Good code and bad code do exist. I don't care if the person writing bad code had a bad hair day, it's still bad code.

Richard Kuo
Wednesday, March 24, 2004

"That's pretty wishy-washy.  Good code and bad code do exist"

All code is bad code to someone, somewhere. This is a very important lesson to learn.

Dennis Forbes
Wednesday, March 24, 2004

All code is bad to someone somewhere.  If that is to say:
. There is always someone that can do the job better than yourself.
. That code can always be improved upon.
. That we don't live in a world of perfection.

These are all truisms.

Nevertheless, there is no excuse for the heaping steaming piles of crap that get passed off for software.

If its true that there is someone who can code better than yourself (and its almost always true), and if you're constantly pushing bugs into the field and someone is always cleaning up your mess, then its time to do some LEARNING about what consitutes good code practice.

Too many excuses for lamery.  That is all.  Quit.

Wednesday, March 24, 2004

I just gotta continue.

We aren't talking about style or even full use of language features.  Although fully understanding a language's features can make you a more productive coder and can vastly aid your creations of beautiful elegance, that is not the point.

The point is creating minimal objects which perform their tasks.  Its about giving careful thought as to what this "thing" you're writing is supposed to DO, not necessarily how you write it.  Its about minimizing dependencies, documenting them and being careful about how state is handled.

To not even TRY, is an abomination and to make excuses as lame as "walk a mile in someone's sandals" is just pure bullshit.

Getting "over oneself" is knowing that there are better ways of doing things and that the world is a big interesting place.  You probably did not invent something new today, nor will you tomorrow.  Mostly, you follow some good practices which others have already laid before you.  Get one with it.  Don't be a dumb ass.

Wednesday, March 24, 2004

"If its true that there is someone who can code better than yourself"

And here you expose your naivety about what constitutes "good" or "bad" code in general discussions such as these -- when someone walks into a new position, immediately pontificates about the horrors of the code that they find, they haven't elevated themselves to superior coder: At that point they've done nothing more than fulfilled a tired cliche for programmers.

Over the past couple of days I've read a variety of the interviews on Artima from industry heavyweights (people who actually created the languages), and it's hilarious how diametrically opposed some of their opinions are about what constitutes good practices and thus good code. It's always fascinating when some low level grunt comes onto online boards and proclaims that it's all black and white, cut and dry.

Dennis Forbes
Wednesday, March 24, 2004

Pah! Snort! Grunt!

One lame generalization deserves another.  Put on a bikini and we'll go mud wrestling together, right here, right now.  I'll show you what good code is... Slather me up, I'm slippery when wet.

Wednesday, March 24, 2004

People who say there's no such things as good or bad code probably haven't seen really bad code. I wish I could spend a day writing some bad code for them - they'd soon change their tune.

Sure, there's always someone who's a better coder than you. There's probably millions, but that doesn't mean that you can't recognise a steaming pile of crap when you see it.

I never understood the "get over yourself" comments. If you ask me, the main difference between a good coder and a bad one is that good coders know that they can still improve and are continuously trying to do so.

Thursday, March 25, 2004

Just to clarify, my position is not that there isn't steaming turd code that has no redeeming qualities (there is), but rather that the other end -- "good" code -- is entirely subjective, and to someone somewhere I'm sure every piece of code ever written is bad code, and often it can be backed up with justifiable, debatable reasons.

Even technological progression turns good code into bad code - A lot of "spaghetti" C code became bad code when C++ came out in a lot of people's eyes. .NET loosely typed collections will become bad code when generics come out in the 2.0 Framework.

Dennis Forbes
Thursday, March 25, 2004

Dennis Forbes describes a very real tendency for every programmer to dislike code they've inherited, simply because it isn't how they would approach the problem.  Perhaps we'd generally rather make the world conform to us than conform to it ourselves, even a small part of it.

But setting that aside, the existence of very, very bad code is also very real.  One should be wary of the tendency Dennis Forbes described, but sometimes -- hell, often! -- we really do find very bad code.  That there are vast differences in programmer skill, care, and talent is no mere illusion of ego.

Thursday, March 25, 2004

From John R. Searl, a giant in cognitive science & philosophy:

"Well, again, it's very hard to summarize but I would say the university became less self-confident in its elitism. By definition a university has to strive for the best. If you're not striving for the best you're not the best university, you're not doing all that you can. But the best means that some things are better than others. Some professors are better than other professors, some books are better than other books. Some ideas are intelligent, other ideas are stupid. And a university has to be committed to quality. It's nothing mysterious, it's like the San Francisco '49ers. They try to get the best coaches and the best players and make them do the best they can. Well we're supposedly trying to get the very best professors and the very best students, and that means intellectually the best -- the intellectual elite of the country as the professors, and the intellectual elite of the state and people from out of state as the students -- and make them perform at the highest possible level. Well, we're still committed to that but we're more bashful about saying it in public. And there is a sort of an undercurrent that, well, maybe that's all a really kind of disguised power structure and maybe it's all a sort of disguised oppression and colonialism, and we've got to get out of this idea that some books are really superior to others, and some students are superior to others, and some professors are better than others. And that's bad. I mean, if you don't believe in quality, and you don't believe that the ultimate criterion of success in this game is what's better and what's worse, what has the quality and what lacks the quality, then you've given up on the ideal of academic life. And I don't want to overstate this. I don't want to say we've abandoned our elitism. But we're less self-confident than we were in the fifties and in the sixties."

I am personally sick and tired of a-holes and their little kiddy, politically correct notion that, "Oh, there's really no good or bad code.  No good or bad programmers.  Let's all just love each other, people." 

The software industry in this country is dying because management and (surprisingly) the software engineering community are completely ignoring the fact that some code is better than other code.  We need to grow up and become real intellectuals, real craftsmen, and real professionals. 

Thursday, March 25, 2004

Of course one extreme shouldn't replace the other.
So yes one should recognise that some things are worse enough to require improvement, but one should also realise that worse does not automatically mean enough to get upset about.

The intelligence is in recognising when which attitude should take precedence.

Thursday, March 25, 2004

"To not even TRY, is an abomination and to make excuses as lame as "walk a mile in someone's sandals" is just pure bullshit."

Do or do not, there is no try.

Mr Jack
Thursday, March 25, 2004

"All code is understandable to someone at some point in time.  Usually the original programmer understands their code for a short while after it has been written"

I utterly disagree.

At $FORMER_EMPLOYER I used to happen across a lot of people who were, essentially, pottering about with bits of code.

They didn't understand where they were or where they were going in a file they were writing at that point in time. You could point to code they'd written five minutes ago and they didn't know why they wrote it, or what it was for, they'd just put it in because most of the other parts of the program had something that looked sort of like that.

They'd copy in half a linked list handling system, and then not use them. Instead they'd hand write code, instead of calling the one still on their screen, and they'd get it WRONG instead of even reading & copying the one on screen.

I'd see people mindlessly copying lines of code about, and SHUFFLING THEM in the hope that one iteration would achieve what they wanted.

No... there really is bad code that has never had understanding applied to it.

Katie Lucas
Thursday, March 25, 2004

" We need to grow up and become real intellectuals, real craftsmen, and real professionals. "

You're a fool and utterly failed to catch any of the points so obviously made.

I don't like the constructs of Perl, therefore all Perl is bad code. Is this a fair statement? It fits entirely within your childish, inane concept of good and bad.

Actually, I'm curious - clearly in your imaginary world there is one penultimate programming language, clearly superior to all others: Which is it?

Thursday, March 25, 2004

Good code and bad doesn't exist?  So there is no difference in maintainability of a 3000-line program implemented as a single function, and another that does the same thing but has things structured into methods of 50 lines or less?  And there is no difference between a system that uses 200 global variables to communicate between modules, vs. another that uses function parameters?  Get real.

Just because you don't write good code doesn't mean it doesn't exist.

T. Norman
Thursday, March 25, 2004

You're a fool and utterly failed to catch any of the points so obviously made.

You don't like to grow up, therefore every grown up is bad. Is this a fair statement? It fits entirely within your childish, inane concept of good and bad.

Actually, I'm curious - clearly in your imaginary world there is one penultimate opinion, clearly superior to all others: Which is it?

Thursday, March 25, 2004

>> "Actually, I'm curious - clearly in your imaginary world there is one penultimate programming language, clearly superior to all others: Which is it?"

This post is so incredibly f'ing retarded, I can't even believe it.  Honestly, I can't believe that someone could possibly be so incredibly f'ing dimwitted as to fit this much retardation into such a small post.

How did your tiny brain come up with this steaming pile of inference?  Where did I even mention programming languages?  Even if I did, how do you figure that the existence of good & bad code means that there must be one best language? 

How the flock can a language be both penultimate and superior to all others?  You are a moron.  Please do humanity the courtesy of committing suicide before you're able to pass on your splendid genes.


Thursday, March 25, 2004

Should you be hanging around adult boards like this anon? Clearly you're just a little kid, and like a cocky kid boasting after their first Karate class you're nothing but talk. I suspect that you don't have a single professional line of code in your portfolio, otherwise you might be a bit more humbled by experience. It is always legitimately debatable whether a particular codeset is good or not, as factors such as efficiency, scalability, and maintainability often conflict, and many people weight them differently.

You have clearly painted the world as right or wrong, a simple binary choice, with One True Way(TM) of software development, and only the cowardly pussies dare to consider it a subjective art that isn't as clear to categorize. Big men like yourselves are willing to call it like it is, though, right?

How did programming languages come up? They came up as a natural conclusion of your vitriolic rheotric, as each is the result of a programmer materializing their own "programming best practices" - Larry Wall wanted something simple, powerful, and that got the job done with all of the fluff. If I program a script in Perl, I am effectively doing so because I believe that philosophy fits best for that task.

Thursday, March 25, 2004

Would you consider buggy code to be bad?  I do.

Thursday, March 25, 2004

To '.':

I sincerely wish you were somebody's case study.  I am thoroughly thunderstruck that a person could be so devoid of reasoning skills.  I mean, honestly, I wish someone would analyze the correlation between your startling lack of intellectual skills, and the structure of your neocortex, or how much your parents beat you, or your lack of education, or whatever.

Seriously, I don't mean to derail the thread, but I am truly curious...  Does it amaze anyone else that his posts consist completely and entirely of non-sequitors, conjectures, and utter nonsense?  I mean, there isn't a single shred of evidence of rational thought represented.  Lookit, just by the laws of probability, something that this guy's written should make sense - if only by accident.  And I really think this moron believes he is making sense.

Check yourself in, you idiot.  Your brain is worth a lot more to humanity bisected in a jar  in a lab.  Perhaps, in this way, we can figure out how to end tragic genetic mistakes such as yourself.

Thursday, March 25, 2004

Damn. I must admit defeat at the hands of your masterly strokes of debating.

Thursday, March 25, 2004

No, seriously, master-debater, I want you to pick a single sentence - a single phrase from your imbecilic posts, and show me how it follows logically from anything I wrote.  Please be precise.

For example, you complete f'ing dullard, consider this masterful bit of insight:

"You have clearly painted the world as right or wrong, a simple binary choice..."

Read the passage from Searle - or have your mommy read it to you.  Read my post, and please describe in what way I have "have clearly painted the world as right or wrong".  Let me put it more simply for you, you damn simpleton:  How does my statement, "some code is better than other code" imply your clever conclusion, "You have clearly painted the world as right or wrong."

You are a foul cretin, and I wish that you would stop sullying to software engineering profession. 

P.S.  Good luck with that Perl thing, though.

Thursday, March 25, 2004



Smiling politely,

Thursday, March 25, 2004

As they say, there's no accounting for taste. 

But without really defining what 'good' code is there will just be these circular discussions.

I can think of a number of factors which would influence whether or not I put a 'GOOD!' stamp on some code -- same for bad.

If your code weighs more 'good' than 'bad', then it's good, and vice-versa. :)

Thursday, March 25, 2004

>> "But without really defining what 'good' code is there will just be these circular discussions."

Has someone come up with an algorithm to input a work of literature and output BAD/GOOD?  No.  And this is irrelevant.  Do you really think that that is what Searle is postulating?  Of course he isn't.  There are centuries of literary criticism to help us come to terms with what exactly constitutes a 'good' work of literature.  We desperately need this sort of critical approach in software engineering before it's too late.  But managers don't want to see this because they're too eager to insist that little kiddies right out school, with low salaries produce great code.  And little kiddies right out school are eager to claim guru status without honing the craft.

P.S.  BTW, '.', you truly ARE a master-debater.  The biggest master-debater I've seen in a long time.

Thursday, March 25, 2004

Quit quoting me you windbag

Thursday, March 25, 2004

What, is slashdot offline today?

U.R. Tedious
Thursday, March 25, 2004

slashdotters think bad code *is* good code.

Thursday, March 25, 2004

With all the love in the room this should be appropriate

A somewhat humorous and sometimes insightful description of how to write unmaintainable code.


"Use Plural Forms From Other Languages: 

A VMS script kept track of the "statii" returned from various "Vaxen". Esperanto, Klingon and Hobbitese qualify as languages for these purposes. For pseudo-Esperanto pluraloj, add oj. You will be doing your part toward world peace."
"Bedazzling Names: 

Choose variable names with irrelevant emotional connotation. e.g.:

      marypoppins = (superman + starship) / god;

This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about."
"Lower Case l Looks a Lot Like the Digit 1: 

Use lower case l to indicate long constants. e.g. 10l is more likely to be mistaken for 101 that 10L is. Ban any fonts that clearly disambiguate uvw wW gq9 2z 5s il17|!j oO08 `'" ;: ,. m nn rn {[()]}. Be creative."

Thursday, March 25, 2004

There's good code and there's fun code.

Good code is well commented, well structured, well documented, well tested, the test plan is documented, including unit tests, the code is peer reviewed and finally implemented.  Good code starts from a documented business plan, with concept doco, design doco (possibly using UML) and god knows what else.

Unfortunately that kind of code is a major pain in the ass and is not fun to be involved with.

Fun code is well structured, efficient and elegant.

That's all I care about - fun code.
I let the drones do the rest.

Saturday, March 27, 2004

*  Recent Topics

*  Fog Creek Home