<div dir="ltr">Thanks very much for the comprehensive answer.<br>
<br>
Using spaces and tabs for alignment does make the code more readable<br>
to my mind.<br>
<br>
The reason behind my question originally was that the CodingStyle doc states:<br>
<br>
"Outside of comments, documentation and except in Kconfig, spaces are never<br>
used for indentation, and the above example is deliberately broken."<br>
<br>
however most code I have seen is not compliant with that.<br>
<br>
Should the docs be updated?<br>
<br>
Cheers,<br>
Laurence.<br>
<br>
On Mon, Sep 26, 2016 at 10:32:06PM +0300, Andrey Utkin wrote:<br>
> On Mon, Sep 26, 2016 at 06:28:58PM +0100, Laurence Rochfort wrote:<br>
> > Hi all,<br>
> ><br>
> > I've read Documentation/CodingStyle and it states to use 8 character tabs.<br>
> ><br>
> > 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.<br>
> ><br>
> > For instance from usb-skeleton.c:<br>
> ><br>
> > static int skel_probe(struct usb_interface *interface,<br>
> > const struct usb_device_id *id)<br>
> ><br>
> > uses two tabs and 6 spaces, not just tabs like:<br>
> ><br>
> > static int skel_probe(struct usb_interface *interface,<br>
> > const struct usb_device_id *id)<br>
> ><br>
> > or<br>
> ><br>
> > static int skel_probe(struct usb_interface *interface,<br>
> > const struct usb_device_id *id)<br>
> ><br>
> ><br>
> > Is a mixture of tabs and spaces acceptable if it enhances readability? If not, which of the tabs-only forms is correct?<br>
> ><br>
> > Similarly, what about assignment alignment in structs?<br>
><br>
> By my observations, conventional alignment in kernel contributions<br>
> nowadays is N*tab followed by M*space, where M < 8. For details, consult<br>
> "checkpatch --strict" output. It's not a paramount to make all existing<br>
> codebase to pass that check cleanly, but if you are polishing your new<br>
> patch, you can use that as guidance.<br>
><br>
> If you use Vim, see <a href="https://github.com/vivien/vim-linux-coding-style" rel="noreferrer" target="_blank">https://github.com/vivien/vim-linux-coding-style</a> -<br>
> it will indent your code more or less in accordance with coding style,<br>
> also making checkpatch happy.<br>
><br>
> checkpatch in --strict mode actually prefers trailing lines to be<br>
> aligned on opening brace. Tabs and spaces are allowed for such alignment<br>
> (and you _need_ spaces to be able to align like that).<br>
><br>
> So what above vim plugin makes, and what is widely used in kernel<br>
> codebase, is something like this ("|tab--->" or a smaller part<br>
> represents tab character, "." represents space):<br>
><br>
> static int blah_blah_blah(struct usb_interface *interface,<br>
> |tab--->|tab--->|tab--->..const struct usb_device_id *id)<br>
> {<br>
> |tab--->if (1) {<br>
> |tab--->|tab--->int var = blah_blah(interface->foo_bar->baz_fuzz,<br>
> |tab--->|tab--->|tab--->|tab--->....11111111111111 + 111111111111111);<br>
><br>
> Also<br>
><br>
> |tab--->|tab--->|tab--->|tab--->|tab--->|tab--->|tab---> (shown for reference)<br>
> #define DRIVERNAME_REGISTER1_NAMEXXX--->|tab--->0xdead<br>
> #define DRIVERNAME_REGISTER2_NAME_WHICH_IS_LONG>0xdeaf<br>
><br>
> Which looks this way with actual tab characters:<br>
><br>
> #define DRIVERNAME_REGISTER1_NAMEXXX 0xdead<br>
> #define DRIVERNAME_REGISTER2_NAME_WHICH_IS_LONG 0xdeaf<br>
><br>
> This is supposed to be displayed ALWAYS with 8-char tab (this is carved<br>
> in slate of CodingStyle), thus arguments about breaking viewing with<br>
> different tab sizes are to be ignored.<br>
><br>
> To my taste this is not best possible approach, and I would like all<br>
> readers of this thread to check this article:<br>
> <a href="http://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces" rel="noreferrer" target="_blank">http://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces</a><br>
> But, unfortunately, checkpatch is explicitly not happy with that<br>
> approach, giving notices of ERROR and WARNING levels for first example,<br>
> however accepting #define case to be aligned with spaces IIRC.<br>
</div>