Why would people write comment code this way?!

So I am reading code written by others and this comment annoys me a lot:

tc.c_iflag &= ~ IGNBRK; /* enable ignoring break */

I was still learning the code and wanted to comment out part of it to see how it goes but the one-line block comment has made it impossible to comment out a block of code. Why would people comment this way and what good does it do? I thought this is a question about general programming but not particular project so I posted here. Am I missing something here? Is there a name of this style of commenting? Thanks.

Best answer I can give is to someone, it looks prettier.

but the one-line block comment has made it impossible to comment out a block of code

#if 0 is your friend.

Maybe it was written by an old-school C programmer

Arrch:
Best answer I can give is to someone, it looks prettier.

Yes it stands out very well in the code. Have to admit that.

AWOL:

but the one-line block comment has made it impossible to comment out a block of code

#if 0 is your friend.

Maybe it was written by an old-school C programmer

Thanks AWOL! You saved me. I was so focused on finding a commenting way to disable those lines and didn't realize that pre-compiler directives kick ass. Yeah, these codes are seen here:

http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/x56.html

Maybe old-school I guess. I started using C in the 90's and learned both single line and block comments but never have seen this style. I know in my heart I can't nest comments so I try to avoid block comment inside a function. I have block comments before a function to explain it (like doxygen style sometimes).

I use vim’s insert block mode to put in a // in front of every line I want to get rid of. Makes it really clear even without syntax highlighting

^v10jI//^[

You can, of course, comment a block of lines in the Arduino IDE by highlighting them and using Ctrl+Slash and undo it in the same way. Undoing it is sometimes 'interesting' because instead of undoing the comments it adds another set for reasons that I have yet to fathom out.

Commenting out code is banned by all good C/C++ coding standards, because it's too easy to get it (or the subsequent un-commenting) wrong. Use #if 0 ... #endif instead.

I used to comment my code this way... (Ducks)

I really like tacking short comments onto the end of a line of code, but the C compiler I learned on didn't support the // notation, so my only option was to use the notation you showed above. As I understand it the // notation is relatively new. I have found that with the block notation I never mistake a comment for a piece of functional code even without code highlighting.

dc42: Commenting out code is banned by all good C/C++ coding standards, because it's too easy to get it (or the subsequent un-commenting) wrong. Use #if 0 ... #endif instead.

Seems to me that is just as easy to get wrong, and also not recognised by many language-sensitive editors hence giving you no help working out which code is actually enabled in a given situation.

FWIW I'd be happy to use conditional compilation to achieve alternatives in the behaviour or [u]temporarily[/u] disable pieces of code, but I see an awful lot of code where it really isn't temporary and has become a lazy way to leave some code in place 'just in case'. In the absence of any other criteria, I'd say that if it's worth checking in to the source repository then it's permanent enough to justify getting rid of the obsolete code.

dc42: Commenting out code is banned by all good C/C++ coding standards, because it's too easy to get it (or the subsequent un-commenting) wrong. Use #if 0 ... #endif instead.

The objection to this is that a lot of syntax colouring makes it obvious code is commented-out, but not that it is subject to an #if 0, which might be out of view (scrolled out of sight).

Yep, modern IDEs such as eclipse can easily allow you to fold blocks of code away too.

Eclipse greys the background of any lines that are not included because of an #if or #ifdef or whatever, this feature is a Godsend in code that has a lot of conditional stuff based on the current CPU or something, especially if the system is unfamiliar to you and you don’t know what the heck is defined.

Without this feature a lot of code is almost unreadable it’s riddled with so many conditional parts.


Rob

PeterH: FWIW I'd be happy to use conditional compilation to achieve alternatives in the behaviour or [u]temporarily[/u] disable pieces of code, but I see an awful lot of code where it really isn't temporary and has become a lazy way to leave some code in place 'just in case'.

My biggest gripe is with developers who comment- or #if-out code with no explanation of why, leaving other developers who have to maintain the code to guess. I was once asked to write coding guidelines for C# and F#, and one of the items I included was that whenever code is #if'd out, there had to be a comment explaining why and under what circumstances the code might be required again.

I use the compiler directive all the time, for example,

1) block out code from compiler (I never define JUNK)

ifdef JUNK

... ...

endif

2) turn on and off debugging statements

Typically in an include file (*.h)

To compile in debugging code:

define MY_DEBUGGING

To not compile debugging code (just comment out the define)

//#define MY_DEBUGGING

Typically in body of code (*.cpp), I also put label on #endif so I know who it relates to:

if MY_DEBUGGING

Serial.println("Hello world");

endif // MY_DEBUGGING

Sometimes I have multiple levels of compiler directives, e.g.

define MY_DEBUG

define MY_DUMP

if defined(MY_DEBUG) || defined(MY_DUMP)

.. ..

endif // defined(MY_DEBUG) || defined(MY_DUMP)

.. ..

ifdef MY_DEBUG

.. ..

endif // MY_DEBUG

jroorda: I used to comment my code this way... (Ducks)

I really like tacking short comments onto the end of a line of code, but the C compiler I learned on didn't support the // notation, so my only option was to use the notation you showed above. As I understand it the // notation is relatively new. I have found that with the block notation I never mistake a comment for a piece of functional code even without code highlighting.

// is the C++ method of creating comments, /* ... */ is the historical method of creating comments in C, and also used in C++. The C99 standard added // comments to C. So, it depends on what level of standards your old C compiler complied with.

liudr: So I am reading code written by others and this comment annoys me a lot:

tc.c_iflag &= ~ IGNBRK; /* enable ignoring break */

I was still learning the code and wanted to comment out part of it to see how it goes but the one-line block comment has made it impossible to comment out a block of code. Why would people comment this way and what good does it do? I thought this is a question about general programming but not particular project so I posted here. Am I missing something here? Is there a name of this style of commenting? Thanks.

 tc.c_iflag &= ~ IGNBRK; // enable ignoring break 
[code]

Is how i'd do it, i'd only use /* */ to remove an entire block of code, // to remove or comment 1 line. 

For me...

[code]
  if (somevar==10) {
      //do something
    }
  if (somevar==10) 
   {
      //do something
   }

my pet hate is using the nesting brackets on the same line as the comparator statement, I prefer readable code over spaghetti. [/code][/code]

@MichaelMeissner

You're right, of course. I started coding with C in 1978 using the BDS C compiler and CP/M. The comment style was /* */, period. I do use the #ifdef DEBUG...#endif for debugging purposes when I feel the need to keep the debug code around for a while.

I'm actually more appalled by the fact that the comment is telling us -what- is being done (like we couldn't figure that out just by reading the line), versus -why- it is being done. It's like seeing:

x = x + 1; // Add one to the x variable

...like...duh?

It's worse when you see this:

Serial.begin (4800); // set baud rate to 9600

As for the /* ... */ comments on one line, you can probably use vi(m) fairly easily to change them to the other sort of comment.

http://www.gammon.com.au/vi