Hi Joe, On Wed, Jun 10, 2020 at 7:13 PM Joe Perches <j...@perches.com> wrote: > > Ii think this is a not a good change. > > If you read the commit log you provided, it ways > "staying withing 80 columns is certainly still _preferred_"
Yes, but the related email discussions were not about establishing a new hard limit, but about avoiding such hard limits for historical/technical reasons. > With this change, clang would _always_ wrap to 100 columns. That is true, but it means clang-format will start splitting lines in weird ways because it has to work with whatever the code is without changes. If a programmer sees that the lines are too long after applying the formatter, then it is a strong hint the code needs to be rearranged somehow (e.g. creating intermediate results). Hence keeping the limit at 80 means we will get strange arrangements which could have fit in 100 just fine. In fact, I would argue a *wider* limit is better for an automatic formatter, e.g. 120. Even more so considering clang-format is not responsible for the final formatting -- at least not yet :-) -- the developer is. Cheers, Miguel