Re: Coding for Obscurity

["Jos A. Horsmeier" <jos@and.nl>]

Stephan Wilms wrote:
> Alan E & Carmel J Brain wrote:
> > firewind wrote:

> > > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> > >
> > > The
> > > if(foo() || bar())
> > >
> > > construct may seem obfuscated and weird to you, it is the way the logic of
> > > some people's minds work.

> > No further evidence, I rest my case.
> > Would anyone in comp.lang.c like to comment?
 
> Yes, I'll volunteer a little comment: code like that has a lot of
> disadvantages: it is obfuscated (it's only the author wh thinks that
> the code is readable) and it's hard to debug and maintain. It sure
> wouldn't pass through my code inspection.
> 
> To explain: readability of code is not targeted at the author of the
> code or maybe his office pal, it is targeted at someone having to
> read and understand a whole big package of source code, to make
> some important modification or to find a bug a year after the software
> has been written and archived. The author might not even be available
> at this moment. Even the smallest effort helps a lot.
> 
> In detail: I would reqrite the first example like this:
> 
>     /* Sensible comment about what get's allocated. */
>   if ( to == NULL )
>   {
>     to = malloc( sizeof *to);
>     if ( to == NULL ) return NULL;
>   }

Although we're talking about style and taste here (which can't be
discussed IMHO), I jumped into (another thread of) this discussion
because I recognized the construct above. Something like 15 years
ago our team went OO (and gaga too, but that's an entirely different
story ;-) C++ was hardly concipiated yet, so we turned to SmallTalk
and borrowed (read 'stole') some features from that language. We were
still dealing with plain old C though ... 

We wanted to handle 'automatic or global' objects and 'dynamic objects'
(just
to borrow some terminology from C++) in C. Amongst other stuff we came 
up with the following macros:

#define NEW(x) ((x) && !((x)->dyn= NULL) || ((x)= malloc(sizeof *(x)))
&& ((x)->dyn= (x)))
#define OLD(x) free((x)->dyn)

(I'm typing this from the top of my head, so be gentle with me here)

An object was represented by a simple struct. One member of such a
struct 'dyn'
contained the address of the struct itself if it was allocated
dynamically, 
otherwise it would contain a NULL pointer. Given those macros we were
able 
to do things like:

	void foo() {

		obj_t	x;
		obj_t*	y= NULL;

		if (NEW(&x)) 
			/* init x; */

		if (NEW(y))
			/* init *y */

		/* do some useful stuff with x and y here */

		OLD(&x);
		OLD(&y);
	}

The NEW macro registered the fact that the memory of an object was
already there
if it were passed the address of an existing struct. The OLD macro would 
peek at the 'dyn' member and pass it to free (we were simply lucky that
free(NULL)
did what we wanted it to do in those days, but if you tell them
youngsters that,
they won't believe ya ;-)

I'm the one to blame for those macros. I just finished some boring
project using
RPG (I guess it was RPG2, but I don't recall exactly) and I did like
those tagged
statements, i.e.

	foo && bar

where 'bar' would only be executed if 'foo' were true (later RISC chips
even implemented
this nice little feature). Maybe my braincell was damaged by my former
RPG experience,
but I found (and still find) the logic behind this all quite readable.
So you're
at least partly right: 'it's the author who thinks that this is
readable'. But the
fun part of this all is, that our team found this construct (and the
accompanying
macros) quite readable too, I wasn't the only lunatic in town ...

I agree that such a construct shouldn't be written down just to inflate
your
ego, but a carefully constructed (or should I say 'crafted') expression
like
this can be highly readable for those who are at least familiar with it. 

But this notion leads to the question -- how qualified should software
maintaining
people be? If they're overqualified (and this very suitable for the
job), they
don't want this type of job (and vice versa is true too).

kind regards,

Jos aka jos@and.nl