Who's the target? Was: Inline `ifdef style` debugging

[Steven W. Orr]

On 8/8/2011 2:38 PM, Roger wrote:
> > On Mon, Aug 08, 2011 at 01:20:25PM -0400, Steven W. Orr wrote:
>
> > Two things:
> >
> > 1. Worrying about lost cycles every time you call _debug because it checks to
> > see if debug is True is pretty miserly. If you *really* have to worry about
> > that kind of economics then it's questionable whether you're even in the right
> > programming language. Having said that, you can certainly create a function
> > that is defined at startup based on the value of debug. Remember that
> > functions are not declared, their creation is executed.
> >
> > if (( debug ))
> > then
> >      _debug()
> >      {
> >          "$@"
> >          # I do question whether this is a viable construct, versus
> >          # eval "$@"
> >      }
> > else
> >      _debug()
> >      {
> >          :
> >      }
> > fi
> >
> > 2. The other thing is that instead of
> >
> > #!/bin/bash
> > debug=true
> >
> > at the beginning of the file, you can just say:
> >
> > #! /bin/bash
> > : ${debug:=0}   # or false or whatever feels good.
> >
> > Then when you want to run the program with debug turned on, just say:
> >
> > debug=1 prog with various args
> >
> > and the environment variable will override the global variable of the same
> > name in the program, an only set it for the duration of the program.
> >
> > Is this helpful?
>
> Yes.
>
> I've decided to use Mr. Williamson's suggestion:
>
> _debug()
> {
>      [[ $DEBUG != 0 ]]&&  "$@"
> }
>
>
> The reply above was very helpful and might provide people searching for
> "ifdef style debugging" for Bash further info on inline debugging techniques.
>
> The above does complete the task of inline ifdef style debugging, however, I
> think it might confuse or slight hinder readability for some beginners.
>
> I'll flag email and restudy it later as I think this "ifdef style" is the
> better method versus having a function read every time even though it isn't
> executed at all!

Thanks, I think ;-)

But you raise an interesting question: When I write code, am I targeting the 
person who knows less of the language, and so therefore I should dumb my code 
down? Or should I feel free to use the well documented constructs that I went 
out of my way to learn (and of course to doc what I write)?

Imagine a code base of 10s of thousands of lines of bash, where there are no 
shared modules, no arrays, almost no error checking, no local variables, no 
command line option parsing, no anything that's not completely vanilla. In 
short, only constructs that contributed to Sun's succeeding for years at 
foisting the Cshell on people.

Languages come in different sizes. C is small, PL/I is large. I'd categorize 
bash as somewhere in the middle. If you're in high school, then the name of 
the game is to write a program that prints the right answer. If you're a 
professional software engineer, then the name of the game is to write high 
quality, industrial grade code, that is well documented, and targets the 
reader of the code with all the information (s)he needs to understand just 
what this verfluchtiges thing is trying to do.

It can be very frustrating that people will go out of their way to write 
compiled code in painstaking detail, but then when they get to shell scripts, 
they throw their hands up and just get it done with no concept of doing it well.

Two examples: New person out of school is told to write something and to use 
some code that almost does what they want from Big Blue. The guy who wrote the 
code from Big Blue clearly thought that all he knew from Csh should be used in 
his bash scripts.

Only that were
if ( test $? -eq 0 )
...

Another case: There's a guy in a well known Journal of Linux magazine who 
writes a column on bash scripting. He wouldn't know it if he got bashed in the 
face with his junk properly written. He seems hell bent on doing things with 
as many possible processes; basically pushing the limits of what a junior 
Bourne shell guy might have mastered years earlier.

I didn't mean to go on a rant, but this list here should not be another place 
that discourages people from learning more of the language elements that allow 
us to do better work. Obscure features are in the mind of the uneducated. Doc 
your code well, but don't engage in elbow kissing in the misdirected intent to 
make the code simpler.

No?

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net