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

[...] 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.
  • Comment on Re^4: Programming *is* much more than "just writing code".

Replies are listed 'Best First'.
Re^5: Programming *is* much more than "just writing code".
by demerphq (Chancellor) on May 09, 2007 at 12:30 UTC

    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

Re^5: Programming *is* much more than "just writing code".
by polettix (Vicar) on May 09, 2007 at 16:18 UTC
    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.