On 8/15/21 9:07 PM, Amos Jeffries wrote: > The existence of such a style requirement on Factory developers, and > thus need for Squid code to match it for ease of future bug fixing, was > given to me as a reason for ICAP and eCAP feature code staying in the > Factory supplied one-line format despite the remainder of Squid code > back then using two-line.
The above interpretation does not match reality. I continue to urge you to stop describing things that you do not have enough information about to describe accurately, especially things that relate to other people. Statistically speaking, the probability of success for such dangerous attempts has been close to zero (and there is no actual need to describe those things to advance your arguments). > So, between your two responses I gather that there will be no push-back > on a PR adding enforcement of two-line function/method definitions by > astyle 3.1. There is push back, of course -- any large format changes need to justify the expenses they necessarily bring. Whether that push back is enough to block that future PR depends, AFAICT, on Astyle formatting results and the timing of migration to auto results. As previously discussed, we do not want to reformat the same large set of lines twice in a short succession. > It appears to be one of the policy rules not copied over to that page > from the Squid-2 page. The fact that the alleged official formatting rules are not actually documented anywhere explains some of the inconsistencies and makes making future rule setting easier IMO. Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
