On Tue, May 14, 2024 at 08:56:49AM +0100, Bruce Richardson wrote: > On Mon, May 13, 2024 at 09:11:32PM +0200, Morten Brørup wrote: > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > Sent: Monday, 13 May 2024 17.55 > > > > > > On Mon, 13 May 2024 14:08:07 +0100 > > > Ferruh Yigit <ferruh.yi...@amd.com> wrote: > > > > > > > 2. Double tab indentation vs parenthesis align > > > > if (iter->bus != NULL && > > > > - /* not in middle of rte_eth_dev iteration, */ > > > > - iter->class_device == NULL) { > > > > + /* not in middle of rte_eth_dev iteration, */ > > > > + iter->class_device == NULL) { > > > > > > > > DPDK coding guide suggests double tab, but also accepts alignment by > > > > spaces. But as far as I can see most of code has double tab. > > > > Majority of the diff caused because of this rule. > > > > > > > > > I personally am more used the aligned style, and most tools support > > > that. > > > The DPDK one is unique (not done by most other projects). So can we just > > > keep the kernel (what is this clang-format) version. > > > > I personally prefer the double tab. > > It also works with editors showing tab as 4 space indentation. > > > > Mixing tabs and spaces only works if the editor shows tabs as 8 space > > indentation. > > > > Double tab works with both editor configurations. > > > > And there is no confusion if the following block happens to be aligned with > > the following parameters. E.g.: > > > > if fool(x, > > y) > > myfn(); > > > > vs. > > > > if fool(x, > > y) > > myfn(); > > > > +1, I also prefer the double tab too for this reason. The other > consideration is that double tab leads to smaller diffs on refactor - with > aligning brackets if something on the first line changes it could cause > whitespace changes to be needed on all subsequent lines > > Overall, ignoring our individual preferences, since we already have a mix > in DPDK, I think it's infeasible to try and enforce a single standard now. > :-(
-1 to anything that aligns with parameters. it's the most mechanically inconsistent convention ever, hostile to refactoring and causes a requirement to endlessly shift your eyes horizontally when reading code sequentially.
