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

[JD]

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
>