Weblogs Forum - Pardon My French, But This Code Is C.R.A.P.

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Pardon My French, But This Code Is C.R.A.P.

61 replies on 5 pages. Most recent reply: Jul 20, 2007 6:03 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 61 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 17, 2007 2:08 PM

> In other words, with few exceptions, I dislike any
> code when I first look at it. As I become more familiar
> with the problem it is meant to solve, I appreciate more
> the approach the author took.

That's a very good point and well worth mentioning. I've rewritten code on several occasions only to find out why the original coding was done the way it was.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 17, 2007 3:15 PM

I have a very simple metric for crappy code. If it was not written by me in the last 3 weeks, it is most likely crap. The unfortunate side effect of this is that most of the crappy code I see is my own.

Seriously, though, i do have a few rules of thumb. I'm curious as to what is going to be in part 2. Here are some of my gauges for crappiness:

1. code littered with variables that are named SomethingN. myPage1, myPage2, etc.

2. Performing the same operation within 10 lines of each other. I don't know how many times I've seen the same recordset opened multiple times and had to clean up the inevitable mess that leads to.

3. Inconsistent indentation. This is forgivable if the likelihood that many ( > 3 ) people were in the code is > 98%.

4. A member function in a class that gets passed in a member or global variable, and that function then calls a member function that modifies the global variable, then continues processing after the function. Example


void DoSomething(var)
{
    DoSomethingElse();
    var = var + 12;
}

void DoSomethingElse()
{
    m_var = m_var + 1; // increment member variable
}

void GetItDone()
{
    DoSomething(m_var);
}

I have a few others, but these are the biggies. I know these are mainly cosmetic, but it has amazed me, in my experience, how often sloppy looking code is really, really bad. With the exception of entries for an obfuscated code contest, the general look of the code has a pretty high correlation with the functionality, robustness, etc. of the code base.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 17, 2007 4:35 PM

Geraldo Lopes de Souza

Posts: 1
Nickname: geraldols
Registered: Jul, 2007

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 17, 2007 4:59 PM

Very well written blog.
Good balance of sense of humor and content

Congratulations.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 5:02 AM

> Certification does neither guarantee nor enforce
> well-written code. For civil engineering things are
> different because, for example, a badly built bridge can
> cause death, but a badly written spreadsheet application
> cannot (if not used where it's not supposed to be used).

What about a badly written life-critical medical device software? Heavy industrial machinery control software? Aircraft software? Nuclear plant software? Even the spreadsheet you mention can cause a significant damage if the decimal point is in a wrong place.

> People who want to write good code will do so, regardless
> of whether they are certified or not. If someone is a
> certified Java developer does that mean he/she will write
> good Java code? I don't think so.

Certification by itself indeed will not enforce anything. But a company that mandates certification and adherence to a coding standard will ensure that they produce more reliable and maintainable code compared to the one that does not enforce those.

> There are just too many
> factors that determine the quality of code and I think a
> lot of it is in the development process where certain
> things just have to be enforced. Having something like
> C.R.A.P. might be a good idea.

If by many factors you mean e.g. whether curly brace goes in a new line or not, those are marginal style issues not worth sweating over. There are not many factors at all. In fact things are rather black and white - there's good code and there's bad code.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 5:22 AM

> > Certification does neither guarantee nor enforce
> > well-written code. For civil engineering things are
> > different because, for example, a badly built bridge
> can
> > cause death, but a badly written spreadsheet
> application
> > cannot (if not used where it's not supposed to be
> used).
>
> Beyond the differences in consequences, there are more
> fundamental differences between civil engineering and
> software engineering. Much of the rules for civil
> engineering are solidly based on physical laws while the
> "rules" of software engineering are often a matter of
> speculation and taste especially when we are talking about
> evaluating the form of the code rather than its function.

First of all, comparisons are to compare different things that are similar, not the same, therefore it is inevitable to have some difference between the disciplines. The differences are by no means "fundamental", though. There is a lot in common between bridge and software building. One thing that is different is the timescale and the way how building occurs - software is built in seconds to days, while bridges are built in days to years time frames. Software is built by electronic computers, automatically, bridges are built mostly manually by human labor aided by tools and mechanical machinery.
As for speculation and taste, that falls in the architecture area and as we have witnessed since the GOF book was published up, there's a wide common ground in that area, too. That being said, in his last series of works (The Nature of Order), Christopher Alexander argues that there is actually the exact measure for goodness of design, i.e. it is not a matter of taste. But getting into that is beyond the scope of this discussion.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 7:36 AM

> > Certification does neither guarantee nor enforce
> > well-written code. For civil engineering things are
> > different because, for example, a badly built bridge
> can
> > cause death, but a badly written spreadsheet
> application
> > cannot (if not used where it's not supposed to be
> used).
>
> What about a badly written life-critical medical device
> software? Heavy industrial machinery control software?
> Aircraft software? Nuclear plant software? Even the
> spreadsheet you mention can cause a significant damage if
> the decimal point is in a wrong place.
>
> > People who want to write good code will do so,
> regardless
> > of whether they are certified or not. If someone is a
> > certified Java developer does that mean he/she will
> write
> > good Java code? I don't think so.
>
> Certification by itself indeed will not enforce anything.
> But a company that mandates certification and adherence to
> a coding standard will ensure that they produce more
> reliable and maintainable code compared to the one that
> does not enforce those.
>
> > There are just too many
> > factors that determine the quality of code and I think
> a
> > lot of it is in the development process where certain
> > things just have to be enforced. Having something like
> > C.R.A.P. might be a good idea.
>
> If by many factors you mean e.g. whether curly brace goes
> in a new line or not, those are marginal style issues not
> worth sweating over. There are not many factors at all. In
> fact things are rather black and white - there's good code
> and there's bad code.

I just realized that I didn't exactly say what I meant (my fault) :)
When I said there are many factors that determine the quality of code I meant the factors that influence the process of producing code, not factors by which the quality of code is judged. So, what I had in mind were things like time frame, how well the requirements are understood, how easily existing code can be modified, how well the existing code is written (bad code usually invites more bad code), the skill, knowledge and attitude of programmers (and the ability and opportunity to apply that knowledge). Basically, I think things like these are interrelated and they all affect the resulting code.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 7:57 AM

> bad code usually invites more bad code

Good point and something I wish more people realized. Bad code is like a dust-bunny under a bed. It starts of tiny but accumulates more bits of badness over time. What started off as a simple thing becomes a completely unmaintainable monstrosity. For this reason bad code must be killed while it is small and weak. It's kind of like the 'broken windows' theory described in "The Tipping Point". For those not familiar with this concept, it's a theory of urban decay: if there's a house on a block with a broken window that is never fixed, after a while all the windows will be broken and the building next door will start to have broken windows. Eventually people start looking at the whole block as run down and leave. This was the idea behind the increased enforcement around graffiti and turnstile jumping in New York. These were considered petty crimes and not a priority prior to that. This is widely considered to be highly successful.

Bad code is the software equivalent of broken windows and graffiti and people who are allowed to skirt standards and reviews are the turnstile-jumpers. If you don't put the kibosh on this kind of thing right away, it's a slippery slope and hard to regain ground. Unfortunately, I hardly ever see this done.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 8:28 AM

> > bad code usually invites more bad code
>
> Good point and something I wish more people realized. Bad
> code is like a dust-bunny under a bed. It starts of tiny
> but accumulates more bits of badness over time. What
> started off as a simple thing becomes a completely
> unmaintainable monstrosity. For this reason bad code must
> be killed while it is small and weak. It's kind of like
> the 'broken windows' theory described in "The Tipping
> Point". For those not familiar with this concept, it's a
> theory of urban decay: if there's a house on a block with
> a broken window that is never fixed, after a while all the
> windows will be broken and the building next door will
> start to have broken windows. Eventually people start
> looking at the whole block as run down and leave. This
> was the idea behind the increased enforcement around
> graffiti and turnstile jumping in New York. These were
> considered petty crimes and not a priority prior to that.
> This is widely considered to be highly successful.
>
> Bad code is the software equivalent of broken windows and
> graffiti and people who are allowed to skirt standards and
> reviews are the turnstile-jumpers. If you don't put the
> kibosh on this kind of thing right away, it's a slippery
> slope and hard to regain ground. Unfortunately, I hardly
> ever see this done.

There is a whole part of 'The Pragmatic Programmer' that talks about this very same thing.

One of my bosses once upon a time pushed real hard for one of our releases to be a 'clean up' release. No new features. Just bug fixes and while you were in the code, take care of fixing up anything you see that needs adjusting. It is the only time in my career I had ever experienced such a thing and it was amazing because after that release, people worked a little harder to keep the code much more maintainable. I think part of that was simply not wanting to ever do another clean up release. That was grueling on a lot of different levels.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 8:40 AM

> One of my bosses once upon a time pushed real hard for one
> of our releases to be a 'clean up' release. No new
> features. Just bug fixes and while you were in the code,
> take care of fixing up anything you see that needs
> adjusting. It is the only time in my career I had ever
> experienced such a thing and it was amazing because after
> that release, people worked a little harder to keep the
> code much more maintainable. I think part of that was
> simply not wanting to ever do another clean up release.
> That was grueling on a lot of different levels.

Personally, I feel terrible if I take code and make it worse. If something is pretty decently written, I'm not going to mess it up. But if the code is already crap, I'm either going to clean it up or just make some quick changes. If those changes are also crap, I don't lose sleep over it. Trying to make clean changes to crap is often impossible or makes things worse/breaks things.

I'm also more particular about other people's changes to clean code vs. crap. If we are reviewing changes that make a mess of someones decent code, they may be asked to clean up. If the code was already a mess, it's often unfair to expect the developer making changes to resolve the situation.

Maxim Noah Khailo

Posts: 25
Nickname: mempko
Registered: Nov, 2004

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 8:52 AM

Code is only as good as the community you write it in (coworkers, open source, etc). Their motivation, their will, their balls of steel.

In such a community, a general coding style and policy develop naturally (explicitly or not).

If you have the right people work on the right thing, you will get better code. (easier said than done)

Having someone who writes better CRAP code mentor someone who is a little bit less disciplined would work wonders over automated tools.

However since people like certainty, a code beautification process might be good. I see people who have a hard time managing memory in their code and prefer garbage collection to be people who would prefer a code beautification process.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 9:16 AM

> What about a badly written life-critical medical device
> software? Heavy industrial machinery control software?
> Aircraft software? Nuclear plant software? Even the
> spreadsheet you mention can cause a significant damage if
> the decimal point is in a wrong place.

Are you proposing a certification process for developers who work on life critical systems or for all developers, including the one who is going to generate a monthly credit/collections report for a toy store?

> Certification by itself indeed will not enforce anything.
> But a company that mandates certification and adherence to
> a coding standard will ensure that they produce more
> reliable and maintainable code compared to the one that
> does not enforce those.

Producing reliable and maintainable code requires more than certification. Organizations could produce more reliable and maintainable software through some of the following (even if certification is not present): keeping developers trained in the latest developments in the field; encouraging developers to go back to college for more formal education in computer science/engineering; screening new potential hires better; having team leaders work directly with new hires to train them in organizational standards; encouraging developers to share information through Friday (or whichever day your end of week is) afternoon tech talks. To me, certification only insures that people in the field have knowledge of the same techniques, tools, and vocabulary. The application of the techniques and use of the tools can still vary widely.

> If by many factors you mean e.g. whether curly brace goes
> in a new line or not, those are marginal style issues not
> worth sweating over. There are not many factors at all. In
> fact things are rather black and white - there's good code
> and there's bad code.

There's certainly code I like and code I do not. The longer I'm in the field the more I learn to withhold judgment until I know what the program/software system is trying to accomplish. "Information without context is rendered meaningless" - I believe David Gelernter said something akin to this.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 9:37 AM

> If by many factors you mean e.g. whether curly brace goes
> in a new line or not, those are marginal style issues not
> worth sweating over. There are not many factors at all. In
> fact things are rather black and white - there's good code
> and there's bad code.

I'm not sure I buy that there is a lot that is black and white in terms of code quality. I once had a debate with someone over which was the correct way to handle an InputStream in Java:

A:

int aByte;
 
while ((aByte = stream.read()) >= 0) {
  // do stuff
}

byte[] bytes = new byte[1024]; // or other arbitrary number
 
while (stream.read(bytes) >= 0) {
  for (byte b : bytes) {
    // do stuff
  }
}

The person I was debating was absolutely convinced that A is the best way because B requires arbitrary bounds and is not as elegant. I didn't disagree with the sentiments but B, in my experience is faster by a factor of more than 25x for local reads and therefore from a performance perspective, A is bad code.

Who would arbitrate such things or do you think this kind of distinction is outside of the scope of certification. Who would write codes for code? It's pretty easy to say what gauge of wire is needed for a 20 Amp circuit or what tensile strength is required for a given load on a cable of a given length. What would software codes even look like?

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 9:52 AM

> Are you proposing a certification process for developers
> who work on life critical systems or for all developers,
> including the one who is going to generate a monthly
> credit/collections report for a toy store?

My point was that other engineering disciplines have figured out those things because they've been around for a longer period of time. A civil engineer projecting a mile long six-lane bridge must be certified. A software engineer projecting a life-critical or hazardous system is not required to be certified. I think that should change.

> > Certification by itself indeed will not enforce
> anything.

> Producing reliable and maintainable code requires more
> than certification.

Exactly what I've said (see quote above).

As for what's wrong with code and also why, I recommend "The problem with programming" interview with B. Stroustrup. He pretty much listed the main problems with programming today:

http://www.technologyreview.com/Infotech/17831/

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Pardon My French, But This Code Is C.R.A.P.

Posted: Jul 18, 2007 10:27 AM

> First of all, comparisons are to compare different things
> that are similar, not the same, therefore it is inevitable
> to have some difference between the disciplines. The
> differences are by no means "fundamental", though. There
> is a lot in common between bridge and software building.
> One thing that is different is the timescale and the way
> how building occurs - software is built in seconds to
> days, while bridges are built in days to years time
> frames. Software is built by electronic computers,
> automatically, bridges are built mostly manually by human
> labor aided by tools and mechanical machinery.
> As for speculation and taste, that falls in the
> architecture area and as we have witnessed since the GOF
> book was published up, there's a wide common ground in
> that area, too. That being said, in his last series of
> works (The Nature of Order), Christopher Alexander argues
> that there is actually the exact measure for goodness of
> design, i.e. it is not a matter of taste. But getting into
> that is beyond the scope of this discussion.

Good point that comparisons need be similar and not exact. Too often this point is overlooked in using comparisons.

However, the difference pointed out between civil and software engineering is critical. Civil engineers solve problems whose solution is bound by immutable physical laws. Software engineers solve problems whose solution is not even determinable, e.g. asking a user whether or not to save a change implies the developer cannot determine the user's choice. The "soft" in the software makes it a different discipline from, for example, civil engineering. Users of our products have the ability to change requirements on the day of implementation based on a new business line. Two cities needing a bridge between them cannot suddenly partner with another neighboring city at the last minute and decide that a tunnel needs to run from the middle of the bridge to the 3rd city.

Flat View: This topic has 61 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic