in reply to Re: Programming *is* much more than "just writing code".
in thread Programming *is* much more than "just writing code".

A thought experiment; what if I changed a few words in your post?

Looking at some code I wrote six months ago I came across the following lines:

if (in_delete_grace_period()) { ... }

adjust_time( $check )
    if last_order_needs_time_adjustment();

determine_status() unless $errors;

[download]

I was able to dive right in to what is going on with the code without reading any comments.

Replies are listed 'Best First'.
Re^3: Programming *is* much more than "just writing code".
by Rhandom (Curate) on May 08, 2007 at 23:14 UTC
    That would be great... assuming that those subroutines were able to to be passed the 20 variables that are in scope... and assuming that they are able to pass back the two or three variables that they modified.

    You have given a nice contrived example that would certainly work under some conditions - but not this one ((sarcasm)which you "obviously" could've guessed without seeing the code(/sarcasm)). My example came from working code - a small random sample of tens of thousands of lines that are all broken into commented paragraphs. Some sections do look more like what you said - but not often.

    Yes I could break into a subroutine every 10 to 20 lines, but then I have a different problem -- the code is arguably more fragmented and less easy to follow and has to find other ways to pass around variables. Some sections of logic cannot be broken up without severely hampering readability, or without serious code mangling - but they can be broken into paragraphs with comment headings.

    Update: made sure that sarcastic comment is taken as such.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]
      Yes I could break into a subroutine every 10 to 20 lines, but then I have a different problem -- the code is arguably more fragmented and less easy to follow and has to find other ways to pass around variables. Some sections of logic cannot be broken up without severely hampering readability, or without serious code mangling - but they can be broken into paragraphs with comment headings.

      Maybe that's not feasible for your application as it is right now, but the best Smalltalk programmers I know write exceedingly short methods all the time, in almost every language they use.

      I don't think that's an accident.

[reply]
      [...] assuming that those subroutines were able to to be passed the 20 variables that are in scope...
      Any FORTH programmer would immediately jump at your throat for saying this. This is a red flag: if you need to pass around more than 3 variables, you're more than likely doing something wrong, in the realm of factoring. A simple function should never need more than just a few parameters.
[reply]

        I think one should be careful about such rules, while they are useful as rules of thumb I think that truth is that the complexity of code is directly related to the complexity of the domain it is operating within. Where the domain is "messy" the code will be as well.

        Simply because a routine has many parameters does not mean it necessarily poorly written or poorly factored. On the contrary it may mean that the code has been well factored and the core routine needs to provide special behaviour in many different scenarios. I guess a clue that it may be such a case is if you find that the routine with 20 arguments is normally accessed only via wrappers which take only a few parameters.

        ---
        $world=~s/war/peace/g

[reply]
        As I read it, the OP says that chromatic's approach cannot possibly take into account the vast complexity of the piece of code the OP was thinking about. For this reason, the OP is against using subroutines because s?he would need to pass 20 parameters, which matches with your reasons... I hope the FORTH programmers were not actually unleashed!

        Flavio
        perl -ple'$_=reverse' <<<ti.xittelop@oivalf

        Don't fool yourself.
[reply]

      There is certainly the case for long methods/subs/procs/funcs if the code is just following one long sequence of actions. A lot of Delphi code that I maintain does that and I think it's not a bad state for that particular type of code, even though the Delphi IDE has auto code hyperlinking, which is great for skipping from one method to another. On the other hand I find that where there is branching it is best to use short methods/subs/procs/funcs that are preferably no more than one screen long, not actually that different from code 'paragraphs'. I general, what most people really want is not strict adherence to coding standards, but to see most of what they need to at a glance and either a short method/sub/proc/func or a code paragraph should be used where applicable.

      I think the main thing is the advice above the Perlmonks masthead: think about loose coupling. Looser coupling means less copying and pasting should happen. The less copying and pasting, the less need for parallel maintenance and the less chance for hard to find bugs. The two TDDs should facilitate looser coupling. I learned Top Down Design at school (though it doesn't always come naturally) and I'm now (several years too late) trying to get my head into Test Driven Development. I'm too conservative to be into Xtreme refactoring, especially for maintenance, but I have recently found a bit of refactoring to be useful in my own code.

      How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
      Robot Tourist, by Ten Benson

[reply]

In Section Meditations