Home > Patterns & Practices > A Death to overly long methods – please I am begging you!!!!!

A Death to overly long methods – please I am begging you!!!!!

If you happened here by accident or design it matters not, this is a plea to all who find it. The plea is simply this:

“stop writing methods or functions that are overly deep and long”.

Do we really need to be telling each other this anymore? Isn’t this on page 3 of Object Oriented Software Development Part 1? Furthermore this is not a problem that only exists amongst developers who never had a formal training and cut their teeth on VBA. No indeed, I see this all too often and from University taught full time developers. The amount of productive time lost in trying to understand code that follows this pattern drives me crazy and I don’t know about you but I suspect most people are like me and have great trouble in retaining this kind of mess in their heads:

while (some_condition)
{
    switch(some_arg)
    {
        case “arg1″
            if(another_bool)
            {
                //…….etc 
            }
            else
            {
                while(yet_another_condition)
                {
                    if(nest_some_more)
                    {
                        //…ect
                    }
                }
            }
            break;
        case “arg2″
            if(!another_bool)
            {
                //…….etc 
            }
            else
            {
                while(!yet_another_condition)
                {
                    if(!nest_some_more)
                    {
                        //…ect
                    }
                }
            }
            break;
        case “arg4″
            //more of the same;
            break;
        case “arg5″
            ////more of the same;
            break;
    }
    if (some_bool)
    {
        while(another_condition)
        {
            if(another_bool)
            {
                //…….etc
            }
            else
            {
                while(yet_another_condition)
                {
                    for(int i=0;i>10;i++)
                    {
                        if(oh_my_god_another_bool)
                        {
                            //….etc
                        }
                        else if(can_things_go_on_like_this)
                        {
                            //….etc
                        }
                        else
                        {
                            //….etc
                        }
                    }
                 }
            }
        }
    }
    else
        while(here_we_go_again_condition)
        {
            if(and_here_we_go_again_another_bool)
            {
                //…….etc
            }
            else
            {
                while(im_in_agony_now)
                {
                    for(int i=0;i>10;i++)
                    {
                        if(my_brain_explodes)
                        {
                            //….etc
                        }
                        else if(the_project_fails)
                        {
                            //….etc
                        }
                        else
                        {
                            //….etc
                        }
                    }
                    switch(some_arg)
                    {
                        case “arg1″
                            //etc;
                            break;
                        case “arg2″
                            //etc;
                            break;
                        case “arg4″
                            //etc;
                            break;
                        case “arg5″
                            //etc;
                            break;
                    }
                 }
            }
        }
    }
}

Now if you think this is too long then double it or triple it and then see how you feel? If your laughing by this stage then either you have never had to work with this kind of code or your laughter is a spontaneous reaction that is masking what might be better represented by tears, given that you have indeed fallen victim to this too many times. If on the other hand you recognise this as your handy work then pay attention to the message and STOP IT!

Lets face it, we have all been guilty of this at some stage and on likely more than one occasion but when recognised for the misdemeanour that it is, one should immediately do penance and mend one’s ways. So rather than merely announcing the message to cease this practice haste with, it would be remiss to let the moment pass without making some recommendations as to what to do as an alternative. There is bad design at work here: if we think of our methods in terms of behaviour then each method should implement one concise behaviour and if you want keep your concerns separated and observe the SOLID principles, then your classes or modules should be following the single responsibility principle. Long methods / functions usually try to express several concerns in one very crowded space, making the code hard to understand and progressively difficult to maintain - time to refactor!

Share/Save/Bookmark

  1. Robert
    May 12th, 2009 at 11:02 | #1

    I would walk into your cube and beat you with a baseball bat if you coded like that. :-)

    [Reply]

  2. Fadzlan
    May 12th, 2009 at 12:27 | #2

    Hear hear. I feel you man. :-D

    Lucky nowadays its relatively much easier to do extract method refactoring in the IDE itself.

    [Reply]

  3. May 12th, 2009 at 19:47 | #3

    Great post, I totally agree that long methods are the biggest code “smell” you can find in an application and you should always refactor them.

    [Reply]

  4. May 12th, 2009 at 20:31 | #4

    Alberto & Fadzlan

    Yes it’s the simplest thing that any developer could do to support more understandable and maintainable code.

    [Reply]

  5. Frank Silbermann
    May 13th, 2009 at 00:32 | #5

    In 1983 a friend told me of an environmental sciences professor who had a program with a 30-page procedure. He assigned his grad student to modularize the program into procedures no longer than a page. He took a ruler and began dividing the logic into thirty procedures named “proc1, proc2, …, proc30″ and a main routine that said “Call proc1; (newline) Call proc2; (newline) …”

    To make a program easier to understand you have to break the long procedure into _conceptual_ units, with names that both summarize and distinguish each concept, one from another. This is difficult for the inarticulate but logical fellow who went into computer science because he hated English class.

    [Reply]

  1. May 14th, 2009 at 10:19 | #1

Creative Commons Attribution-ShareAlike 2.5 Australia
Creative Commons Attribution-ShareAlike 2.5 Australia