Re: [E-devel] Re: E CVS: e mandrake

[Kim W. <ki...@wo...>]

Geoff Harrison wrote:
> * on [03.18.04] Kim Woelders <ki...@wo...> scribbled:
> 
>>I'm not going to change my opinion for that reason. It is silly to put
>>in silly code.
>>I don't care too much either, if that the way "you" want it, fine.
>>The problem seems to me that there is no standard way to do this.
>>I like the USE_VAR macro better than the useless unreachable assignment,
>>though :)
> 
> 
> Here's the rationale for having these assignments in the code.
> 
> in many cases, the parameters are there because they are called from a
> generic function pointer or lookup table.  Or, in some cases (like
> fnlib being now optional) they're there because it's used in some
> compile cases and not in others.  When they're useless because you truly
> do not need them you should get rid of them.  For that reason you should
> keep things like -W -Wall -Wmissing-prototypes -Wmissing-declarations
> enabled while developing code.  When there is no way around keeping
> those function parameters in your code for reasons like mentioned above, 
> you should certainly remove those warnings by inserting "silly code that
> is never executed" so that you can see when code is actually
> un-necessary, like the code that I commented out in several places.
> 
> That is my 2c
> 
I'm aware of why one might do these things.
My opinion is never the less that it is plain wrong to put unreachable
statements after a return in a function.
It may be that most compilers interpret this in the spirit it was
intended but that still does not make it right.
Hiding the assignment/reference/whatever in a macro I think is OK, as
the precise workaround to make the compiler of the day happy can be
changed globally in one location.

I refuse to write these useless assignments after returns, but I promise
never to touch or question any of the ones you put in again :)
And if anybody actually bothers to change them into USE_VAR like things
I'll even follow that standard.

/Kim