Re: simpler question about my script

[Dennis Williamson]

On Fri, Feb 18, 2022 at 11:54 AM Sysadmin Lists <
sysadmin.lists@mailfence.com> wrote:

> > Message: 2
> > Date: Thu, 17 Feb 2022 21:11:42 -0500
> > From: Greg Wooledge <greg@wooledge.org>
> > To: help-bash@gnu.org
> > Subject: Re: simpler question about my script
> > >
> > > That's an excellent list except for the (qualified) part about
> cleverness, IMO. If you read through old (I mean 70s and 80s) code, it's
> stuffed with cleverness. Being clever forces a deeper understanding of the
> language in use, forces brevity, and forces tight flow-control. It doesn't
> take away from readability if you comment your code well (which is also a
> dying art probably tied to the advice about cleverness). I see "avoid being
> clever" becoming "be lazy" in the real world.
> >
> > I agree with Dennis here.  What you think is "clever" today is
> "unreadable
> > gibberish, what the hell was I thinking" 6 months from now.  You're just
> > hurting yourself.
> >
> > Also bear in mind that programs written in the 1970s may have needed to
> > work on extremely limited or bizarre systems.  Couple that with compiler
> > optimizations being quite poor, and you had people trying desperately
> > just to get *anything* to work.  It's not a fair comparison to today's
> > needs.
>
> I suspect we're not operating with the same definition of "cleverness"
> here. I've yet to see genuinely clever code that looked like gibberish;
> I've seen plenty of gibberish that was meant to be clever and wasn't. There
> is nothing more satisfying than a brilliantly written recursive function --
> yet the "don't be clever" dictum would suggest not writing them. I've seen
> complex sed and awk scripts written in dozens-of-lines that today would
> take a dozen pages. The modern lack of mental rigor is telling.
>
> And in many cases, lack of brevity leads to lack of readability. I've seen
> far too many bash and shell scripts that were twice as long as they needed
> to be. It's clear when forethought was lacking during their creation.
>
> The "don't be clever" advice is one of those "feels good to say" mantras
> that get passed around in this industry, like "there's no right or wrong
> way to do things in [*nix|programming]." But there are good ways and bad
> ways to do things, and some good ways are better than others. I suppose the
> people that need to hear "don't be clever" are the ones that obey it
> anyway, so no harm done there.
>
> --
> Sent with https://mailfence.com
> Secure and private email
>
>
There are differences (and sometimes overlap) among concise, verbose,
dense, gibberish, time- or space-constrained and "too clever by half"
pieces of code. Sometimes priorities have to be compromised, but
readability and maintainability have to be among the highest because
programmer time remains expensive while hardware cost per performance has
declined. In very small-scale (project life span, for example) or personal
environments sometimes expediency becomes the top priority, but - surprise!
- now your "quick-and-dirty" has become production and the technical debt
starts ballooning.

Also, "good code is self documenting" is not just a feel-good expression,
it works in the real world. Comments can quickly get out of sync with code.

And there are thresholds that have to be considered when making choices in
coding. I don't know of any that are etched in stone in the context I have
in mind. But I have a feel for when I should choose Python instead of Bash
or an algorithm instead of a regex.

Another thing to recognize, and often it's important to document, is that
there are reasons in a particular set of circumstances to make a set of
choices. Those circumstances and choices aren't the same in another
situation. But guidelines such as the ones that I outlined are pretty basic
and general. For someone seeking help here, following them or similar ones
will lead to quicker and more accurate help. If I have to expend a lot more
extra effort to help someone (for free) after having "pulled teeth" there's
a good chance I'll just say "next" and move on.

-- 
Visit serverfault.com to get your system administration questions answered.