[ale] Making the argument for many scripts vs one big one.

[Richard Bronosky]

Yes! Exactly what JD said.

I only make separate scripts if they are intended to be run separately. I
hate needlessly sub-filed code. I don't want to have to jump file to file
to make sense of it when reading the code or making changes. Break complex
scripts up into functions even if they only get called once. A clearly
named function that removes a dozen or so lines from its calling function
is an excellent form of documentation.

If I do intend to script separate tasks, I prefer to avoid the pattern:
monolith_script command arguments [arguments...]

Instead, I create a separate script per task and for the common pieces I
will also define a bash "library" that defines functions but calls none.
This, padawan, is The Way.


On Jul 24, 2013 10:44 AM, "JD" <jdp at algoloma.com> wrote:

> I've written commercial installers in Borne shell. Didn't have any choice.
> I
> always felt "dirty" after.
>
> The key things to reducing bugs in any language is using functions AND no
> function should be larger than 1 screen (including comments).  5-20 real
> lines
> of code tops, plus checking the return code for EVERY call.
>
>
> On 07/24/2013 08:47 AM, Charles Shapiro wrote:
> > Less chance of bugs due to scoping errors
> > Easier to optimize (although you're going to pay a performance price for
> loading
> > more scripts)
> > Easier to document ( scripts should carry their own documentation )
> > Easier to move to new systems ( you can test and modify smaller scripts
> > individually)
> >
> > My general rule of thumb is that once a bash script moves beyond about
> 500
> > lines, it's un-maintainable and should be rewritten in a more suitable
> language.
> >
> > -- CHS
> >
> >
> >
> > On Wed, Jul 24, 2013 at 8:29 AM, leam hall <leamhall at gmail.com
> > <mailto:leamhall at gmail.com>> wrote:
> >
> >     Any supporting ideas for pushing the argument of "Use lots of small
> scripts
> >     for a big task, instead of one large one"?
> >
> >     So far my thoughts are:
> >
> >
> >     Isolation of new, untested functionality
> >     Ease of use when only one part of the task is required
> >     Easier to introduce new programmers
> >     Ease of maintenance since you don't have to look past one screen
> >
> >     Anything else?
> >
> >     Thanks!
> >
> >     Leam
> >
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130724/0e7edae6/attachment.html>