Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re: Re: Re: Linear programming is bad

by chromatic (Archbishop)
on Mar 25, 2002 at 04:10 UTC ( #154014=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Linear programming is bad
in thread Linear programming is bad

There is a definite tradeoff, and it would be silly (or arrogant) for me to write an authoritative rule. Your point about adding modularity potentially introducing bugs is spot on correct. Of course, test freaks would suggest that unit tests will catch that. (Hopefully...)

Besides the complexity concern, I hate to be stuck with a bad interface for backwards compatibility reasons. If you modularize too early, there are two yucky possibilities. Either your interface is too limited for the general uses and you'll have to rewrite code anyway, possibly creating bugs, or you'll have to write an overly generic interface, adding more complexity in the hopes that you'll catch all the ways you might want to call the function.

In my experience, by the third time you use a piece of code, you'll know enough to write a good interface.

Besides all that, the cleaner your code, the easier it will be to modularize. By the time I get over 100 lines, generally I'm writing functions anyway. There's a definite intuitive understanding that's not coming across in my posts very well...

Replies are listed 'Best First'.
Re:^4 Linear programming is bad
by Louis_Wu (Chaplain) on Sep 14, 2003 at 00:08 UTC
    One way to write Ovid's program is to ask yourself what you have to do with this code.
    1. Get the expense info.
    2. Munge the info; in this case, sort by department.
    3. Write a report.
    Once you know what you have to do, you might be able to write the very beginning of the program. In this case, you can write the 3 lines which use the functions you will write later. And if you follow BrowserUK's advice, you can write 'functions' which print OK.

    You've only written code that you need to write - the function names came right out of your task description. The functional nature lends a bit of maintainability. And it keeps you honest about what you're trying to do.

    Perl programming and scheduling in the corporate world, as explained by dragonchild:
    "Uhh ... that'll take me three weeks, broken down as follows: 1 day for coding, the rest for meetings to explain why I only need 1 day for coding."

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://154014]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2018-05-21 23:21 GMT
Find Nodes?
    Voting Booth?