Julian Elischer schrieb:
David Malone wrote:
As I said, the point of a style guide is consistency. Changing it
doesn't promote consistency, so there needs to be a good reason for
the change, rather than a good reason not to change. In my opinion,
there isn't a strong reason. Similarly for parens around return
values - there's nothing (substantial) wrong with either rule, so
they should probably be left as-is.
Many of the previous changes to style(9) came from cases where
the existing rules led to programmers increasing their chances
of making errors, or people found themselves often misinterpreting
code in the same way, over and over again. Changing them to bring
them closer to someone's personal style has never been an acceptable
reason. There is a barrier to entry that any change must overcome
which is "It will decrease code consistency (by definition) so
it it worth it?" .
For every proposed changed, I presented comprehensible reasons why I
propose it. I never used "because I like it" as a pseudo-reason. Yes,
these changes reflect my personal preferences, but they are my
preferences for a reason and I try really hard to convey these reasons.
"parens on return statements is an example.. there are some posibilities
as to what one can do with this, but I really do find that the parens
are part of the style that I'd notice as inconsistent.
What does this mean in one simple sentence? Should the clause be removed
so they may not be added anymore?
Christoph
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
