Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1298914

Re: On Lindent shortcomings and massive style fixing

Path csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!bofh.it!news.nic.it!robomod
From Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Newsgroups linux.kernel
Subject Re: On Lindent shortcomings and massive style fixing
Date Tue, 29 Dec 2015 10:20:01 +0100
Message-ID <qKYBH-6TY-3@gated-at.bofh.it> (permalink)
References <qKH7Q-3lo-11@gated-at.bofh.it> <qKI3U-402-19@gated-at.bofh.it> <qKX2V-5J4-5@gated-at.bofh.it>
X-Original-To Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=corp-bluecherry-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VqMp26cm3VEqH3BYTUoqMI6luJycXY4zCNBT0hn3EPQ=; b=MKAwJwPgFjaiY8tBDwp2mLaqULpdKDbaFyIU2ClU2Xqc+C+i09d9Pe5t9fvbLsmvi9 kdnUCg8HtcAnEBpDIndlAu3DlqRt0y14cqC6caIYJ/7GQaXMwLxi1kyRQqmtcjY1SwPn sn6ye1QkudrC5hRu+qTPrOng9JrpMZ+59tf9X16Vn1WSK7YsNlqEZE3v7kprSOEGQvhm CIPZgNb4QDSpQOoJDcLKiBoW050Mg/ud6jSNdNkP3Yk92WqzrvsmAqybmsjhbFKvQTnM uHhpHiyPGFbhAVMGsM90SW7B11SHnXXePxVnAMvK+Ops1EuRBNPzRZVWs1Sn2Nmz2KhP z9uQ==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VqMp26cm3VEqH3BYTUoqMI6luJycXY4zCNBT0hn3EPQ=; b=hb7OPo2fZfGOIhu3etXDYsPN8x4xgxmafh5qWlYVkzBdJU7Wei90RVdYyZ0XkvdOtA E18bAaX75pYqeu6lfogpENFiPHxYbmuuZI3lJKN3Z4ngiv3YmJrhFiNXoBQjuGfaX2iJ H/vJkQW7+JqIWsbnts5uKHisHeijq8/xLgDGGEdcJR1ChVvJrodXPNGV5dykn7jtDIJb gglgsMsOszDbqfBB7FE/m0RWXjoEiXPQkLWklGzy6Q+lXymjVZUvcLdMoglfzbVpZPOr 3iGqIw8OMxaSem1T8qfyTWAXfCPKtz3cPYklR88hN8lVF3SnvVvQkscC6svpdPjSR5/0 1rQQ==
X-Gm-Message-State ALoCoQk0LIqF8muX2ojOZ2nA+qEFqXJOBoLbQhQGTvfMyB55oFIjrUyapoMexsVbNIuFT+WCBMYd5UEqi4tbyClOHJc/MXtm11Ojsr/dbT0TTFDH2eYG6XM=
MIME-Version 1.0
X-Received by 10.50.138.2 with SMTP id qm2mr33971903igb.91.1451380325474; Tue, 29 Dec 2015 01:12:05 -0800 (PST)
Content-Type text/plain; charset=UTF-8
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 71
Organization linux.* mail to news gateway
X-Original-Cc Greg KH <greg@kroah.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, kernel-janitors <kernel-janitors@vger.kernel.org>, "kernel-mentors@selenic.com" <kernel-mentors@selenic.com>, Linux Media <linux-media@vger.kernel.org>, devel@driverdev.osuosl.org, andrey.od.utkin@gmail.com, Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>
X-Original-Date Tue, 29 Dec 2015 11:12:05 +0200
X-Original-Message-ID <CAM_ZknVEadva2RbM+EJXCguNx+GVfkEPVPwrrKtXCp+X14XDSw@mail.gmail.com>
X-Original-References <CAM_ZknVmAnoa=+BA9Q+BSJ_dKwtBWWXHqZyJ_BH=FppqGLpFUg@mail.gmail.com> <20151228153332.GA6159@kroah.com> <20151229053235.1d2ccb9c@recife.lan>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1298914

Show key headers only | View raw


On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
<mchehab@osg.samsung.com> wrote:
> IMHO, there are two problems by letting indent breaking long
> lines:
>
> 1) indent would break strings on printks. This is something that we don't
> want to break strings on multiple lines in the Kernel;

Yeah, GNU indent does its work badly (although I believe it could be
taught to respect long literals), this makes me want to have a better
tool for clean "relayouting" C code.
I believe that'd require at last a proper syntax parser. With such
tool, it would be straightforward to rewrite source code automatically
to please any demanding reviewer of code style, except for issues of
higher level of thought (like naming or nesting limitations).

> 2) It doesn't actually solve the problem of having too complex loops,
> with is why the 80 columns warning is meant to warn. Worse than that,
> if a piece of code is inside more than 4 or 5 indentation levels, the
> resulting code of using indent for 80-cols line break is a total crap.

Then I'd propose to enforce nesting limitation explicitly, because
Documentation/CodingStyle appreciates low nesting, just doesn't give
exact numbers.
It's better this way, because the programmer could pay attention to N
places of excessive nesting and fix it manually, and then carelessly
reformat NNN places of "80 chars" issues automatically, comparing to
reviewing all NNN places, to figure out if there's excessive nesting,
or not.
(CCed checkpatch.pl maintainers.)

> That's said, on a quick look at the driver, it seems that the 80-cols
> violations are mostly (if not all) on the comments, like:
>
>         int i_poc_lsb = (frame_seqno_in_gop << 1); /* why multiplied by two? TODO try without multiplication */
>
> and
>
> #define TW5864_UNDEF_REG_0x0224 0x0224  /* Undeclared in spec (or not yet added to tw5864-reg.h) but used */
> #define TW5864_UNDEF_REG_0x4014 0x4014  /* Undeclared in spec (or not yet added to tw5864-reg.h) but used */
> #define TW5864_UNDEF_REG_0xA800 0xA800  /* Undeclared in spec (or not yet added to tw5864-reg.h) but used */
>
> Btw, the content of tw5864-reg-undefined.h is weird... Why not just
> add the stuff there at tw5864-reg.h and remove the comments for all
> defines there?

tw5864-reg-undefined.h will be edited for sure (maybe dropped), of
course it won't stay as it is now.
It was generated by script during reverse-engineering that bastard
chip from hell.

> Also, Lindent already did some crappy 80-cols like breaks, like:
>
> static int pci_i2c_multi_read(struct tw5864_dev *dev, u8 devid, u8 devfn, u8 *buf,
>                        u32 count)
>
> (count is misaligned with the open parenthesis)

I just added "static " after indenting.
Actually, Documentation/CodingStyle says nothing about alignment of
function declaration tail on open parenthesis.
Also I'd like to mention that I hate such alignment, because it
requires intermixing of tabs and spaces. I am not aware if this is K&R
thing or not. If it is, then please don't kill me.

Thanks for kind replies, gentlemen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

On Lindent shortcomings and massive style fixing Andrey Utkin <andrey.utkin@corp.bluecherry.net> - 2015-12-28 15:40 +0100
  Re: On Lindent shortcomings and massive style fixing Greg KH <greg@kroah.com> - 2015-12-28 16:40 +0100
    Re: On Lindent shortcomings and massive style fixing Mauro Carvalho Chehab <mchehab@osg.samsung.com> - 2015-12-29 08:40 +0100
      Re: On Lindent shortcomings and massive style fixing Andrey Utkin <andrey.utkin@corp.bluecherry.net> - 2015-12-29 10:20 +0100
        Re: On Lindent shortcomings and massive style fixing Julia Lawall <julia.lawall@lip6.fr> - 2015-12-29 11:20 +0100

csiph-web