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