On Thu, 2017-12-14 at 20:34 +0100, Lennart Poettering wrote: > Well, the idea is that /* */ is used for explanatory comments and // > is left for local, temporary, non-commitable stuff. > > i.e. if you are testing some stuff, and want to comment out some bits > briefly, use //, but if you add explanations for code that shall be > commited then please use /* */. That way you can see very easily what > is temporary stuff you should fix up before commiting and what should > go in. > > different projects have different rules there. Some people use "FIXME" > or "XXX" for this purpose (and in fact its up to you if you do, after > all this kind of stuff should never end up being commited upstream), > but so far we just used C vs. C++ comments for this, and I think that > makes sense.
It doesn't really make sense. Most comments are until end of line, and '//' is the natural match for that. That's what the comment feature in most other languages does too. '/*' comments take more space, are more effort to type, and cause extra problems with unterminated comments. There can be variation in whether you use '/*' for larger block comments etc, but IMO it's not at all reasonable to say that the standard comment marker is suddenly reserved for "TODO" stuff only in one project. I consider such banning of "random" features about as reasonable as "in our project you must not use the newfangled a->b operator, you have to write (*a).b" - that is, not reasonable at all. I'm also generally opposed to arguments like "different projects have different rules" for completely arbitrary rules with no real rationale. Standardization and best practices have value. Again, this is IMO comparable to the position of the systemd project. "Our project just happens to require you do stuff differently or require old C dialects" is analogous to "well our Linux distro just happens to use different paths etc for no real reason beyond historical accident, you should just deal with that". I checked CODING_STYLE, and the entries that look like they're ultimately purely the result of resistance to change without any valid justification are: - trying to prohibit // comments - trying to prohibit free declaration placement - it's often better for readable code, and the reason against it is really just not being used to reading such code - trying to prohibit variable declarations together with function invocations. "int res = func(foo);" is perfectly reasonable code. Again, just a matter of getting used to reading such code. These could be replaced with more modern best practices, for example: // This form implies you use the value of "i" after the loop for (i = 0; i < n; i++) ...; // Use this form if the value of "i" after the loop does not matter for (int i = 0; i < n; i++) ...; _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
