in reply to When do you function?

Hopefully most of the time. :-)

Seriously I find that my average function is about 10 lines. Some are shorter - a lot shorter. A few are much longer. But that seems to be an average for me.

Here is a list of reasons from chapter 5 of Code Complete to think about. I won't copy explanations, just the reasons:

  1. Reducing complexity
  2. Avoiding duplicate code
  3. Limiting effects of changes
  4. Hiding sequences
  5. Improving performance (optimize later)
  6. Making central points of control
  7. Hiding data structures
  8. Hiding global data
  9. Hiding pointer operations
  10. Promoting code reuse
  11. Planning for a family of programs
  12. Making a section of code reusable
  13. Improving portability
  14. Isolating complex operations
  15. Isolating use of non-standard language functions
  16. Simplifying complicated boolean tests
I have found that all of these benefits still hold in Perl. Well performance is usually hit a little, but you are left in a position to optimize where it counts later. And you shouldn't have non-standard language functions. But in practice I have noticed portability issues from time to time.

So while that list doesn't hold perfectly for Perl, it is still generally on target.

Note that in particular comments explaining what you intended at one point are not a good substitute for clear code. Should you change the code later, the comments will often remain to confuse you. Also deeply nested loops may not take many lines, but they make it much harder to separate the forest from the trees.

Replies are listed 'Best First'.
Re: Re (tilly) 1: When do you function?
by a (Friar) on Dec 27, 2000 at 09:44 UTC
    when I was mid-BS (ahem) in CS, I used to write all my programs "top down"; just create a bunch of function/procedure names that'd handle the problem and pencil in the loops (on the backs of output pages, w/ a couple of sheets for 'global' vars and page for function prototypes, details to be filled in later). As a mid-level programmer now, performance is so rarely a concern (what I write runs less often (e.g. daily) than its worth to squeeze (or 'bum') any extra speed out of it0) that the value of a clean loop calling meaingfully named functions outweighs any loss in the internal context switches etc.

    Keeping the flow clean and localizing the gritty details makes life much easier, and makes the final program that much more maintainable: its way easier to rewrite &Get_Image_Path to handle the addition of a separate image server box than to go back and find and handle all the spots that were calling "Get_Image_Path($case_number, $document_number)"

    a

[reply]
Re: Re (tilly) 1: When do you function?
by puck (Scribe) on Dec 28, 2000 at 02:33 UTC
    As in a's comment, I also tend to write top down using wishful programming. (Where wishful programming is using names of functions I haven't written yet.) This has the benefit of not having to think about everything at once, and if you create stub functions it will actually run and you can slowly build it up. Ah ha, starting to use some XP techniques! (Except I learnt to do this before XP was around...)

    When it comes to breaking functions up, if I have a function which is trying to do several different things, it is usually time to break it up. Likewise, a function which is more than a couple of screens long is about due for a break up. Although the screens one is very relative... Especially when I'm writing CGI scripts which are generating forms, they can get rather lengthy.

    Over the last couple of weeks I've been writing a interface for managing Spong - using Perl OO. In an object, if I realise that I need to use some code again (for example: sucking details out of the database about a host), it get's broken out to a new function in the object.

    So, there's some of my approaches. Of course, if I sat down and did some decent design before hand I'd only need to use the first one - wishful programming - as the functions would already be broken up logically.

    Sigh...

    Updated: Right, that link to Spong now works as it should. My bad. (Thanks a for pointing it out!)

[reply]
      Oh, you are so on the nail on this... I've gotten into a habit of doing this instead of writting pseudo-code: 
      # authenticate user
AuthenticateUser($foo,$bar) 
    or die('Could not authenticate user');

# a while later...

# do some stuff
SomeStuff($more,@params)
    or die('Could not do more stuff cause reason');

# subs from here down
########################
sub AuthenticateUser {
    return(1);
}

sub SomeStuff {
    return(1);
}

      [download]
      I tend to code this way especially when I'm discussing the program with colleages. Then we all get a copy and each one goes out to fill in his/her respective blanks. In the end, I believe the result is usually very clear and quite maintainable!

      #!/home/bbq/bin/perl
      # Trust no1!
[reply]
[d/l]

In Section Meditations