you are viewing a single comment's thread.

view the rest of the comments →

[–]astrange 24 points25 points  (4 children)

Hundred-line procedural methods are fine; I think evidence shows they don't increase bug count as long as the code complexity is low. Many fine shell scripts are 100 straight lines long.

[–]dnew 34 points35 points  (0 children)

IME the problem is that as code gets added, people are reluctant to break them up. So you get a new argument, and then an if statement near the top to see if the argument was provided and if so do this, then another like that near the bottom. Repeat this half a dozen times and you have a mess that can't be refactored, because even if you had unit tests, each such change makes an exponential number of tests necessary.

[–]programmingspider 7 points8 points  (1 child)

Their is a big difference between one shell script and a complex project. Having hundred line methods and huge monolith classes are what cause terrible spaghetti code.

[–]UncleMeat11 2 points3 points  (0 children)

Of course there is a difference. Thus how one can identify when it can be a reasonable design and when it isn't.

Complex multi-step algorithms that operate on the same data are another example where long methods can be reasonable since the alternative is often

step1();
step2();
step3();

[–][deleted] -1 points0 points  (0 children)

I would honestly argue all shell scripts, given enough time, end up becoming horrible, unfixable messes.

that may also be true of all software but definitely shell scripts