The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

2000 line method call

Looking over the source code for the open source project sakai: http://www.sakaiproject.org/, One of their main classes has a 2000 line method that has 50 cases in a switch statement. Class SiteAction, method buildContextForTemplate(...).

Normally I would think something went wrong in the design process when a method gets this long. What are your thoughts?
anon
Tuesday, April 10, 2007
 
 
Sorry, my comma ruined the link up above. Here is a good link.

http://www.sakaiproject.org/
anon
Tuesday, April 10, 2007
 
 
"50 cases in a switch statement" would be okay, IF it's a "transaction center", and IF there's not too many methods like that.

It would be hard to maintain, though, unless broken up by comments into sub-sections, each of which was a few lines.
AllanL5
Tuesday, April 10, 2007
 
 
2000 lines is nothing -- at my last company we outsourced a part of our project, and one of their methods had 80,000 lines! (It was to draw a default 3D object -- the list of triangles was in a file but they hardcoded DrawTriangle(...) for each and every triangle, instead of (say) reading the file into an array at run time and looping through it).
John
Tuesday, April 10, 2007
 
 
80000 lines of DrawTriangle is a WTF, no comparison.
onanon
Tuesday, April 10, 2007
 
 
_instead of (say) reading the file into an array_

I've seen that mistake before and it always puzzles me. It's almost like people would rather do something simple and rote 500 times, rather than make some (slighly) trickier code _once_ to create a data table and be done with it.

Aside from that obvious problem, the most common huge methods are easily refactored, and they usually look like this:

if (contextString.equals("submit"))
{
...100 lines
} else if (contextString.equals("editField"))
{
...200 lines
} else if (contextString.equals("recalc"))
{
...150 lines
}

etc, etc and on for 1000s of lines.
mynameishere
Tuesday, April 10, 2007
 
 
They were blindly following the theory.
Well, you know how to optimize the loop - you need to unroll it... :-)
asmguru62 Send private email
Tuesday, April 10, 2007
 
 
Hmmm... appears to be an Open Source project used predominantly in education.  Therefore, I would wager that the vast majority of people who work on it are either a) students or b) professors.  Neither of which normally have much real-world experience... and if you want to extend it further, many of these participants are likely to make their contribution over the span of a year or two and then move on.  System maintenance is not likely to be a high concern.
KC Send private email
Tuesday, April 10, 2007
 
 
Joshua Kerievsky's _Refactoring to Patterns_ has a good section on using the Command pattern to get rid of nasty switch statements like that.
Kyralessa Send private email
Tuesday, April 10, 2007
 
 
I once -personally- wrote a 2400 line function.

Ah, the joys of doing complex things in Javascript :)
Some guy
Tuesday, April 10, 2007
 
 
A little off-topic:
The open-source project does not have some of the nicest code we've ever seen...any exception to this just confirms the rule.
It's the nature - the programmers as a whole are just that - an average whole, as in every other profession and/or craft.
The open-source projects IMHO are just a playground for amateurs or students currently learning to program, so it's a little naive to expect idealistic promises like "there are hundreds of eyes that will see the code, so its quality must be nothing but great".
I'm not trying to say that closed source are superior to open-source as a code quality. Just the crap is everywhere...the truth is that the customers are seem to accept the whole average/crappy software and wanting for more...
The code quality is a personal decision and striving, only a few (top X%) are doing that...and the people like that read forums/blog like JoS to share and/or read opinions, because they care about what they do.

Now back to the topic:
I'm currently rewrite the main logic of an application dealing with states, guess what - ~1200 function with switch statement, with a 7 or 8 levels of nesting (switch -> if -> switch -> if -> if -> switch...)...so, this is not that uncommon. I'm rewriting it as a state design pattern in order to make myself comfortable and to make my life easier because the change requests are lurking behind the corner.
Singulus Send private email
Wednesday, April 11, 2007
 
 
"It's almost like people would rather do something simple and rote 500 times, rather than make some (slighly) trickier code _once_ to create a data table and be done with it."

They probably got paid by the hour...
Chris Nahr Send private email
Wednesday, April 11, 2007
 
 
or used LOC as a performance metric, lol
AH
Wednesday, April 11, 2007
 
 
I like using LOC as a performance metric! The more of them I rip out during the day without losing functionality, the happier I am when I get home.
mjfgates Send private email
Wednesday, April 11, 2007
 
 
"The open-source projects IMHO are just a playground for amateurs or students currently learning to program"

Some are, but most of those projects are relatively small and never get more than a handful of users.  To lump Firefox, PHP, Apache, Eclipse, etc in with those is foolish.
KC Send private email
Wednesday, April 11, 2007
 
 
How much code duplication there is?  2,000 lines long method is not a problem by itself, but it might be a symptom.
If there is a lot of code duplication, the command pattern or replacing switch with polymorphism can result in code that is more concise and easier to read.
If there's little or no code duplication, then don't fix what ain't broken.
Jeff Zanooda Send private email
Wednesday, April 11, 2007
 
 
"It's almost like people would rather do something simple and rote 500 times, rather than make some (slighly) trickier code _once_ to create a data table and be done with it."

Or maybe, it started simple and got more complicated as time went on.  There may have been no point when there was quite enough pain to justify rewriting, or reliability was more important than pretty code, or _____.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Wednesday, April 11, 2007
 
 
"Reliability was more important"

Your claiming this method was more reliable.

As to being faster, I seriously doubt that it was indeed faster.  I find doing things right the first time saves me a lot of time in the future.

Thursday, April 12, 2007
 
 
>They probably got paid by the hour...

Or expected to be typing non-stop, easiest way to do that is to turn yourself into a human macro expander.
dot for this one
Thursday, April 12, 2007
 
 
"Reliability was more important"

'Your claiming this method was more reliable.'

Nope.  I said maybe reliability was more important.  Suppose the code works.  A rewrite will either work (no gain in that area) or will not work (ouch!).

'As to being faster, I seriously doubt that it was indeed faster.  I find doing things right the first time saves me a lot of time in the future.'

Doubt means that you do not know.  Why not find out instead of spouting off?

As to doing it right the first time, that may well have been done.  The right thing can change over time though.  I am on my eleventh year maintaining a client billing system.  This is version 2 and was a total rewrite.  The right thing has changed many, many times.

There have also been blind alleys, but we had little way to tell until we tried.  "That's just what I said, but it's not what I want."  I simply try again using the knowledge that I gained from the failed effort.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Thursday, April 12, 2007
 
 
"Suppose the code works.  A rewrite will either work (no gain in that area) or will not work (ouch!)."

Bless you. These are words to live by. Few developers I know can resist changing something that works fine because "the original author should have done it this way."
A. Nonymous
Friday, April 13, 2007
 
 
I suspect the 80,000 line call was created by a code generator. At least I hope so!
dot for this one
Friday, April 13, 2007
 
 
What are these mysterious code generators that people mention from time to time?  Other than GUI tools, what else is going to be creating lots and lots of auto-generated code?  I wouldn't know because I don't ever use any.  I guess I can actually program.  :P
CodeClarity
Monday, April 16, 2007
 
 
> Normally I would think something went wrong in the design process when a method gets this long. What are your thoughts?

That would be a "you're buying the drinks for everybody else for the rest of the year" offence here.

Seriously though - such code wouldn't make it past review here.
Anna-Jayne Metcalfe Send private email
Monday, April 16, 2007
 
 
CodeClarity: You can write code generators yourself.
Frederik Slijkerman
Tuesday, April 17, 2007
 
 
"What are these mysterious code generators that people mention from time to time?  Other than GUI tools, what else is going to be creating lots and lots of auto-generated code?  I wouldn't know because I don't ever use any.  I guess I can actually program.  :P"

I can program, too!  Among the many things that I can program are code generators.

It can give a higher-level view.  There is enough detail in programming that I am happy to pass some of it off to the computer when the computer can handle it.  The same sort of reasoning is why we have compilers.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, April 17, 2007
 
 
I've seen such a function in the main loop of a bytecode interpreter written in C. There were hundreds of cases, most of which were pretty simple, and the authors desperately wanted to avoid the overhead of a function call for every opcode.

In that example, I think it was actually the best solution. Splitting the function into related groups would have added extra if/then logic for every opcode (which messes up the pipeline). Having a function for every opcode would basically get you a maze of little functions, all similar. It wouldn't actually be more readable, just more code.

It was eventually replaced by a superior design which had _fewer opcodes_. The operations that really needed high performance had their own opcode, and all the rest were under a single opcode for "call builtin function".

All in all, I think the length of a function doesn't impact readability as long as it's a flat switch/case construct.
Richard Braakman Send private email
Saturday, May 05, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz