[squid-dev] Coding Style updates

[Amos Jeffries]

On 13/08/21 4:28 am, Alex Rousskov wrote:
> 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).
> 

I don't mean that as a bad thing. Just that I am aware that Factory is a 
large contributor who prefers the one-line style.


> 
>> 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.
> 

Hmm. Okay.

> 
>> 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.
> 

It can support both now. If we don't have agreement on a change I will 
implement enforcement of the existing style policy.


> 
>> 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.
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>