Wine code comments

[James McKenzie]

Frédéric Delanoy wrote:
> On Sat, Jun 5, 2010 at 05:38, James McKenzie 
> <jjmckenzie51 at earthlink.net <mailto:jjmckenzie51 at earthlink.net>> wrote:
>
>     John Voltz wrote:
>
>         Hi everyone,
>
>         I have a question about comments in the Wine code. I noticed while
>         tracking down a bug that a lot of the code comments are using the
>         block comment marker /*. This is a royal pain when trying to
>         comment
>         out large sections of code where there are a bunch of /* foo */
>         comments. Why is this allowed? Is there are way around it without
>         having to change them all to //?
>          
>
>     Simple answer:  We use 'c' comment convention because some
>     compilers choke on the C++ style.
>
>     You could use #if (0) and should use this to mark out possible
>     locations for buggy code as it was noted elsewhere.  Using /* and
>     */ is not good coding practice to comment out code.
>
>      James McKenzie
>
>
> > (E. Hoover)
> >Particularly, the section entitled "Avoid C++, C99 and non-portable C
> >constructs."
>
> Actually, aside from debugging functions, and stuff in headers files, 
> "if (0)" would be more portable than "#if 0", with the additional 
> advantage that it leads to less code rot, since obsolete code tends to 
> be deleted earlier, and not simply forgotten.
>
> Besides, it shouldn't incur any runtime penalty, since "if (0)" blocks 
> are typically discarded at compile time.
>
If that works better, then use it.  The OP was trying to block out 
sections of code that were causing problems to attempt isolate and then 
fix them.

Some problems are introduced just because the API code is incomplete and 
needs a little 'filling out' with properly designed and engineered 
code.  This cannot be iffed out.

> What do you think about it?
>
Also if (0)'d code should have a comment block on when and why it was 
removed and what must be done to re-incorporate it and if someone is 
working on it, a name and durable contact information.  Also, an 
anticpated completion date, if known, should be entered.  Reliance on a 
particular release is not sufficient.

James McKenzie