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

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.

Ron

On 1/14/19 23:33, Andrej Rode wrote:
> Hi,
>
> On Mon, 14 Jan 2019 23:03:40 -0800
> Ron Economos <w6rz@comcast.net> 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
> changes.
>
> 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!
>
> Cheers
> Andrej
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio