From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756381AbcH2VI1 (ORCPT ); Mon, 29 Aug 2016 17:08:27 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:55543 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756252AbcH2VIZ (ORCPT ); Mon, 29 Aug 2016 17:08:25 -0400 From: Arnd Bergmann To: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ? Date: Mon, 29 Aug 2016 23:07:59 +0200 User-Agent: KMail/1.12.2 (Linux/4.7.0-rc7+; KDE/4.3.2; x86_64; ; ) Cc: Joe Perches , "Luck, Tony" , "Levin, Alexander" , Greg KH , Sasha Levin , LKML References: <1472330452.26978.23.camel@perches.com> <3908561D78D1C84285E8C5FCA982C28F3A1B3222@ORSMSX114.amr.corp.intel.com> <1472493700.3425.67.camel@perches.com> In-Reply-To: <1472493700.3425.67.camel@perches.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201608292307.59835.arnd@arndb.de> X-Provags-ID: V03:K0:lMIFHRO+BPFjP5igW3peMs4qvd/rnFGNPepof40nUfLv/BaVzAR RdbtKOWpzePQa+U2cCN4zOnRQzn3JBKt2HCd6Zwwfc7BUiEg2AOgAJr6/ffpFcZdctPEOgR Q6le1BswCey2oyFfWJ3KGLp+r6y+kNsM64a1+JkjPn773XpDurDAO07JaxiNvGHkg8c/hCh aKoCun7Xyr9qEOuXGKz8w== X-UI-Out-Filterresults: notjunk:1;V01:K0:rsHasb6I31M=:EiuXj22xFhA1F0J3VmHmiD 3r5atiEn0p7wAYyPgPygioVJ/IdzGwj4Giz5i4DElrsdGfbodDcIHPG/USgiH/e7NVpEJHd15 tSkTKWMaYIZKiwLgeowdmBJvOYZ7v2eEb+Bx/kqLaCm51YQ2nue25oT6UIgbhUvs6o94WDagV O+C0Sc46W70yBxAqKY5IoofXqDSaJJ1lZMrgThO/bnhAq6VWNl74Fum5ctQgtjBOOl/v78YJS ViE2Dh1TYt+XoMpt2t+svJPouEN1wMJpWY1bEl+XSmq48esXmtsuKp8KKzEDTudMVb1Km8VXi xMfUesMex0P7nSHGNGtj72DWeKslkkj+IRrXgEIQD7KW76aUoqFKS2hQGpv0Dasj7x2VYzXge BwrdEatr0qFqkJb/GyE5mNW2YMWjcEkAcQ6yJ7s5EzLnQibn5xVW9oYKVI32RscIpzPomJ+/T zYuYFl2ZX5Io/G9jCM4VTYtIZsJR7cBa2X8QUdFNc15NuyiIzBjnCQxoxeOgrDtSS90Zbbis7 GJyql41QTqafeJ7873A+1r2vFXTStJhcgfxLUqXbcBGjfFkcWZPrVVIqgdrcNcjvP4Na6kzPp CJvTPTBO3NEJ577SQTfPSlnvUCE2FnLvKlCPF9dMsOif8ExheFHFhvxGuLfl4zsmexAC4BTm2 DhBTOBo1fLIPa4NKJR6AYIqKQujxYzVi+tADostn3dnXmhA4B9nQthrWcQ5PuAMJNi4kwft2V vl0Io7SVp9SNRFLZ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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