Hia ll!
On Mon, 2016-09-26 at 18:28 +0100, Laurence Rochfort wrote:
> [...]
> I've read Documentation/CodingStyle and it states to use 8 character
> tabs.
That means, that a <tab> uses up to eight columns and not that one
should replacre some 8 spaces somewhere with a <tab> or that spaces are
not allowed.
> Reading several USB driver files including drivers/usb/usb-
> skeleton.c, I see that multi-line lists of argument and operands are
> often aligned on top of each other using a mixture of tabs and
> spaces. checkpatch doesn't complain about the mixture.
Why should that be a problem.
> For instance from usb-skeleton.c:
>
> static int skel_probe(struct usb_interface *interface,
> const struct usb_device_id *id)
>
> uses two tabs and 6 spaces, not just tabs like:
>
> static int skel_probe(struct usb_interface *interface,
> const struct usb_device_id *id)
>
> or
>
> static int skel_probe(struct usb_interface *interface,
> const struct usb_device_id *id)
Which of the three versions is most readable/consistent?
IMHO the first (and it is the only consistent).
Consider more than 2 paramaters which I align as in
---- snip ----
static int foobarfunc(struct usb_interface *interface,
const struct usb_device_id *id,
int whatever,
const char *and_a_string)
---- snip ----
Would it be "better" as
---- snip ----
static int foobarfunc(
struct usb_interface *interface,
const struct usb_device_id *id,
int
whatever,
const char *and_a_string
)
----
snip ----
(which is also somewhat used somewhere)?
That wastes two
lines IMHO.
Same for
---- snip ----
static int
foobarfunc(
struct usb_interface *interface,
const struct usb_device_id *id,
int
whatever,
const char *and_a_string
)
----
snip ----
which has the motivation "I can grep the function body with
^functionname" (but in the light of IDEs and `ctags` isn't that
important anymore).
And remember that we are here for 99% in the "what one is used to" department.
> Is a mixture of tabs and spaces acceptable if it enhances
> readability?
Only readability is really important - not some document (describing
the rough direction to go an gives some simple direct hints for the
undisputed details) or output of some simple script/tool which tries to
detect violations[0].
Both of them are just guidelines and do not justify a single patch
stupidly and blindly just "correcting" some checkpatch complaint.
Actually "checkpatch" needs some "do not warn in the next n lines"
mechanism (or similar, e.g. `indent` and probably all source code
formatters hava that too) so that known/intended violations for good
reason are silenced.
Bernd
[0]: And "checkpatch" is a good tool but it is just a tool and one
needs to see the source to decide if it's better - not the simple
warning of eome reg-exp.
--
Bernd Petrovitsch Email : bernd@xxxxxxxxxxxxxxxxxxx
LUGA : http://www.luga.at
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
