[squid-dev] Coding Style updates

[Alex Rousskov]

On 8/12/21 12:42 AM, Amos Jeffries wrote:

> 1) return type on separate line from function definition.
> 
> Current style requirement:
> 
>   template<...>
>   void
>   foo(...)
>   {
>     ...
>   }
> 
> AFAIK, this based on GNU project style preferences from the far past
> when Squid had a tight relationship with GNU. Today we have a conflict
> between Factory code coming in with the alternative same-line style
> and/or various developers being confused by the mix of code they are
> touching.

AFAIK, Factory developers try to follow the official style (while
keeping the old code consistent), just like all the other developers
(should) do. They make mistakes just like all other developers do. It is
unfortunate that you felt it is necessary to single out a group of
developers in a negative way (that is completely irrelevant to your
actual proposal).


> IMO; it is easier to work with the one-line style when command-line
> editing, and irrelevant when using more advanced tools.

FWIW, I do not find it easier to use one-line style when using
command-line tools. In fact, the opposite is probably true in my experience.


> As such I propose converting Squid to the same-line style:
> 
>   template<...>
>   void foo(...)
>   {
>     ...
>   }
> 
> 
> Opinions?

One-line stile increases horizontal wrapping, especially when the return
type is complex/long and there are additional markers like "static",
"inline", and "[[ noreturn ]]".

One line approach itself is inconsistent because template<> is on the
other line(s).

Searching for a function name with unknown-to-searcher or complex return
type becomes a bit more difficult when using "git log -L" and similar tools.

In many cases, function parameters should be on multiple lines as well.
Their alignment would look worse if the function name does not start the
line.

Most function definitions will have "auto" return type after we upgrade
to C++14. Whether that makes one-line style more or less attractive is
debatable, but it is an important factor in delaying related changes.

Eventually, we may be able to automatically remove explicit return types
using one of the clang-tidy tools, but such a tool does not exist yet
(modernize-use-trailing-return-type comes close but is not it).

In summary, I recommend delaying this decision until C++14. However, if
others insist on changing the format and changing it now, then I will
not block these changes, assuming newer astyle produces reasonable results.


Can new astyle support multiline formatting? If not, _that_ could be a
strong argument for changing the style.


> 2) braces on one-liner conditional blocks
> 
> Current code style is a bit confused. We have it as a style to use, with
> exceptions for some old macros etc where the lack of braces causes
> compile issues or bugs.
> 
> Personally I prefer the non-braced style. But it seems far safer to
> automate the always-brace style and not have those special exceptions.
> 
> Opinions?

I also prefer the non-braced style for simple expressions.

Perhaps there is a way to automatically wrap complex ones, for some
reasonable definition of "complex"?

Alex.