[systemd-devel] Fragile journal interleaving

[Uoti Urpala]

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++)
   ...;