[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [GREP] GNU Radio Coding Guidelines

From: Ron Economos
Subject: Re: [Discuss-gnuradio] [GREP] GNU Radio Coding Guidelines
Date: Tue, 15 Jan 2019 00:10:16 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

Here are my old style .clang-format changes:

-AllowShortFunctionsOnASingleLine: All
+AllowShortFunctionsOnASingleLine: None

-AlwaysBreakAfterDefinitionReturnType: None
-AlwaysBreakAfterReturnType: None
+AlwaysBreakAfterDefinitionReturnType: All
+AlwaysBreakAfterReturnType: All

-  BeforeElse:      false
+  BeforeElse:      true

-Cpp11BracedListStyle: false
+Cpp11BracedListStyle: true

-IndentCaseLabels: false
-IndentWidth: 4
+IndentCaseLabels: true
+IndentWidth: 2

-NamespaceIndentation: None
+NamespaceIndentation: All

-PointerAlignment: Left
+PointerAlignment: Right

-SpaceAfterCStyleCast: false
+SpaceAfterCStyleCast: true

The two major changes are 2 space indent versus 4 and namespace indentation.


On 1/14/19 23:33, Andrej Rode wrote:

On Mon, 14 Jan 2019 23:03:40 -0800
Ron Economos <address@hidden> wrote:

I realize that I'm late to the game, but I was recently reminded of
this GREP (and it's associated GREP 0011). I'm all for cleaning the
code, but the current .clang-format rules create a problem (that's
addressed in GREP 0011).
Yeah, a bit late, but with valid arguments nonetheless.
Specifically, the current .clang-format would change the files so
much, that the repository history would become useless. In GREP 0011,
this is referred to as a "history reset".
Reformatting everything in one commit will make it easy to jump this
single commit if going back in git blame or in git log. Still all
functional (relevant) changes are visible to the observer.
Mitigating "large" code changes by crafting a .clang-format comapatible
to the old, non-enforced, coding guideline will result in "medium" code

At that point it's not really clear if one would have a benefit of
changing only half of the code (since it's very likely to be the
"important" half). And thus the .clang-format was crafted to have the
most pleasant coding experience.

Also while editing old files the formatting was all over the place in
relevant places (where the functional code lives). Usually header &
footer is formatted uniformly.
I'd like to suggest a middle ground. A .clang-format can easily be
crafted that uses the old GNU Radio guidelines. This would provide
minimal changes to the files, and a "history reset" would be avoided
(or at least mitigated).
Personally I'm not really keen to touch the formatting again, but I'd
like to hear other opinions. But to be honest, I don't really care, as
long as the formatting is enforced automatically. Otherwise formatting
is futile.

Thanks for chiming in!


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]