On Monday 29 August 2016, Joe Perches wrote: > On Mon, 2016-08-29 at 17:46 +0000, Luck, Tony wrote: > > > > > > 80 columns is simply silly when dealing with either > > > long identifiers or many levels of indentation. > > > > > > One thing that 80 column limit does do is encourage > > > shorter identifiers and fewer levels of indentation. > > > > > > Generally, both of those are good things. > > I think the main complaint with the limit is that people fix it by simply > > breaking the long line, which often makes for less readable code. > > > > Perhaps there would be less pushback on this if checkpatch also > > complained about clumsily broken long lines and offered the advice > > to restructure the code with helper functions etc. to avoid deep > > indentation? > > It suggests that already for 6+ leading tabs, but some more > intelligence for nominally ugly added line breaks would > definitely help. > > Using longish simple identifiers or multiple dereferences > can make the line breaks at 80 columns silly.
My preferred personal guideline for the maximum indentation is the area that a function takes up in the editor. It's sometimes ok to have really long functions (hundreds of lines), but only with one or two levels of indentation. It's also sometimes ok to have five or six levels of intendation, but only if the function is really short and you can see immediately how it works. Having a long function with multiple nested loops and conditions is almost always a problem for readability, and we should be able to detect this programatically if we want to. There are more accurate ways to tell if you are getting too complex (e.g. CONFIG_GCC_PLUGIN_CYC_COMPLEXITY), but that becomes harder to warn about. Arnd