On 2/19/2024 10:26 AM, Bruce Richardson wrote: > On Sun, Feb 18, 2024 at 11:05:35AM +0100, Morten Brørup wrote: >>> From: Stephen Hemminger [mailto:step...@networkplumber.org] >>> Sent: Saturday, 17 February 2024 19.11 >>> >>> On Sat, 17 Feb 2024 19:02:30 +0100 >>> Morten Brørup <m...@smartsharesystems.com> wrote: >>> >>>> Not formally... it follows the official DPDK Coding Style [1]. >>>> >>>> [1]: >>> https://doc.dpdk.org/guides/contributing/coding_style.html#general >>>> >>>>> Should be: >>>>> >>>>> if ((ol_flags & RTE_MBUF_F_TX_TCP_SEG) == 0 && >>>>> (ol_flags & RTE_MBUF_F_TX_UDP_SEG) == 0) >>>>> goto clean_txd; >>>> >>>> This indentation style is mentioned as an alternative in the guide. >>> But the example in the guide also uses two tabs for a similar long >>> comparison. >>>> >>>> Personally, I also prefer the style suggested by Stephen, so we might >>> want to update the Coding Style. ;-) >>> >>> >>> The two tabs is an Intel thing, and I prefer the kernel, line up the >>> conditional style. >> >> I prefer 4 space indentation, which is sufficient to notice the indentation. >> 8 spaces seems overkill to me, and quickly makes the lines too long. >> With the editor configured to show tab as 4 spaces, the kernel alignment >> style ends up with the same indentation for the condition and the code block: >> >> if (a && >> b) >> ctr++; >> >> Whereas with the "tab as 4 spaces" editor configuration, the double >> indentation style clearly separates the continued condition from code block: >> >> if (a && >> b) >> ctr++; >> > > These two above are the main reasons I much prefer the double indent on > continuation, though I'd also add a third one: it means we don't have a mix > of tabs and spaces for indentation. > > However, as stated already indent can be a matter of taste, and there will > be some disagreement about it. The existing coding standards document what > was done in the code base when they were written, and I don't think we > should look to change them. It's a bit annoying having 2 standards for > continuation rather than 1, but it's not exactly a free-for-all, and it's > not something that applies to every line, only to a small subset. >
++1
