[C] Why do people write comments using /* ... */ ?

mina86 · 06-29-2014, 08:07 AM

Quote:

Originally Posted by metaschima

So then, how do you comment out code ?

If it's not needed, just delete it…

metaschima · 06-29-2014, 11:03 AM

Quote:

Originally Posted by mina86

If it's not needed, just delete it…

Well yes, but what about when you are debugging ? Say you want to test two or more pieces of code ? Yes, you can do it with the preprocessor, but smeezekitty said he hates it. So, if he hates the preprocessor but doesn't mind /**/ comments everywhere, then what is his solution ? I thought maybe he had one. Of course, it could be just a rant.

smeezekitty · 06-29-2014, 12:01 PM

The problem with abusing the preprocessor like that is the code path become unclear.
Usually I just use /* */ to comment it out. That is one disadvantage of using those
comments in code is that you lose that ability. I still don't mind them though

When I am testing sometimes I mark the code position and cut the code and paste it to another file.

mina86 · 06-29-2014, 12:08 PM

Quote:

Originally Posted by smeezekitty

When I am testing sometimes I mark the code position and cut the code and paste it to another file.

Or one can delete the code, build debug version, and then undo changes on the file (any serious editor has that functionality). Or rename a function to something else while they test its different implementation. Or add code at its beginning and add “return” at the end of the new code so that the old one is unreachable. Or even wrap the code in “if (0) { … }”.

There are so many options that I don't recall when was the last time I used “#if 0”.

metaschima · 06-29-2014, 12:13 PM

Quote:

Originally Posted by mina86

Or even wrap the code in “if (0) { … }”.

That is also a possibility.

NevemTeve · 06-29-2014, 12:15 PM

I don't really get what are we talking about, but I think that's what "if" is good for.

Code:

if (options.debug>=1) {
    fprintf (stderr, "Debug: x=%d, y=%d\n", x, y);
}

ntubski · 06-29-2014, 12:30 PM

Quote:

Originally Posted by mina86

and if you're using reasonable editor you probably can configure it to enter comments with some simple keystroke

Yeah, I don't know why anyone would write comment markers by hand. In Emacs, I can just use comment-dwim (M-;) which comments or uncomments the marked region. For example, with all the code marked, comment-dwim toggles between these 2:

Code:

#include <stdio.h>

int main() {
    printf("hello world");      /* a comment */
    return 0;
}

Code:

/* #include <stdio.h> */

/* int main() { */
/*     printf("hello world");      /\* a comment *\/ */
/*     return 0; */
/* } */

As you can see, it handles existing /* */ comments by escaping the comment markers.

metaschima · 06-29-2014, 01:25 PM

Certainly most IDEs can handle things properly. However, you can't just assume that everyone has a good IDE. I mean why else are Linux kernel devs so strict about style ? With a good IDE you can set your own style, but ... they're still strict about it.

mina86 · 06-29-2014, 02:15 PM

Quote:

Originally Posted by metaschima

Certainly most IDEs can handle things properly. However, you can't just assume that everyone has a good IDE. I mean why else are Linux kernel devs so strict about style ? With a good IDE you can set your own style, but ... they're still strict about it.

For one, code is not always read in an IDE. For example, a lot of kernel code I read, I read in my mail client (or LKML archives).

If someone writing code does not have a decent editor, then their first priority is to get one, and not worry about comment style.

rtmistler · 06-30-2014, 06:31 AM

I end up using #if 0 #else #endif a lot because there are some prototype projects where they change the lower sensory layers a lot because they want to test which are better, but we want to keep the capability to talk to the other ones until we reach a final conclusion. As a result it's better to take the entire function and #if 0 it out until we know which direction we're going in.

The other thing there is if you try to /* */ the whole function, any random comment in the middle of that screws your attempt up.

And #if 0 is not perfect either, you have to have legal code within it. Make a file with bad syntax or just non-code within #if 0 and it won't always compile if you happen to have syntax based terms in there, for instance ";".

All a matter of preference though. I'm glad that C is C and I rarely encounter anyone's code that is unreadable; bad maybe, but not unreadable.

mina86 · 06-30-2014, 08:54 AM

Quote:

Originally Posted by rtmistler

I end up using #if 0 #else #endif a lot because there are some prototype projects where they change the lower sensory layers a lot because they want to test which are better, but we want to keep the capability to talk to the other ones until we reach a final conclusion. As a result it's better to take the entire function and #if 0 it out until we know which direction we're going in.

In that case, define a macro and do “#if THAT_MACRO” and not “#if 0”, e.g.:

Code:

#define USE_NEW_API

/* … */

#ifdef USE_NEW_API

void do_foo(void) {
	do_something();
	do_something_else_using_new_api();
	finalise_or_something();
}

#else

void do_foo(void) {
	do_something_completely_different();
	use_the_old_api();
}

#endif

/* … */

int main(void) {
	/* … */
	do_foo()
	/* … */
}

#endif

rtmistler · 06-30-2014, 09:00 AM

LOL Mina86, not in the project I'm on; the hardware changes come rapidly for "experiementation" purposes and then suddenly I have to support both in one software release (therefore no preprocessor directive but instead true if-else). The coupe de grace is "can we get BOTH of those at the same time so we can parallel their data under the same test conditions?"

Nobody uses it, then everybody uses it, the suddenly an entirely new sensor is miraculously found that does it all. ... and then I'm keeping track of three sensory outputs.

mina86 · 06-30-2014, 09:47 AM

So you're saying you can use “#if 0”, but you cannot use “#if TEST_MACRO”? I'm confused.

Also, VCS is your friend, delete what is not needed at given time, and bring it back if it later is needed again.

rtmistler · 06-30-2014, 10:10 AM

No I could do that if it were my choice, it isn't.

I am saying that ultimately when they ask me to support "either or" as a configuration option, that preprocessor directives are useless at that point because all code will need to be included in the final result. And then further when they ask me to have parallel processes or threads talking to both sensors; recording the data from both at the same time so they can run a field test and compare the data - once again preprocessor directives are a moot point. In fact, in those situations, the "either or" case is a minor headache, the "both at the same time" case is an architectural expansion where I have to write a lot more code; also fully knowing that eventually much of it will be going away ... until someone long in the future says "You know ... we were getting better readings way back when we were using the <blah-blah> sensor ..." So a lot of this is the "R" part of R&D.

In thinking a bit further though on #if 0 versus #ifdef _SOME_WORDS_; I actually do not prefer unclear words for the reason that I see _TEST_MACRO_ or something like that and then I have to FIGURE OUT if that is ever declared. That's inconvenient. #if 0 is 100% clear, "This code is NOT included in the compilation".

I have a colleague who uses #ifdev _NEVER_ where they have #define _NEVER_ 0 somewhere. Yeah ... cool.

I don't mind that you choose to do what you do, please don't worry about my style. But like I say, this brief discussion has made me realize that I do like #if 0 because it is clear as to its intention.

AnanthaP · 07-01-2014, 12:42 AM

Back to /* */ pair .v. //

/* */ pairs permit comments to spread over more than one line.
Unless that is you prefer a long, loopy winding, wrapped around line where the entire comment is only visible if you have set your editor to wrap lines).

So it is more useful to comment out entire chunks of code or text spread over many lines with one pair. (in // you would have to comment out each and every line and god help you in debugging if you forgot one line and more specially if you had to revert back after testing and forgot one line).

Also old c compilers may not permit //.

On the flip side, /* */ type comments within comments don't always work correctly. (// has eliminated the problem).

My choice : use both appropriately.

OK