On 2026-01-28 15:46:08 -0500, Derek Martin wrote:
>   - many, many developers (myself included, but also almost everyone
>     I've worked with) find 2 spaces inadequate for indentation, most
>     especially (but not exclusively) in longer functions with more
>     than 2 or 3 levels of indentation.  If you're not one of those,
>     bully for you, but don't make the rest of us suffer.  Please, use
>     a minimum of 4.

Said like that, this does not make much sense, because there are
several ways to indent. For instance:

  if (cond)
    foo();
  if (cond) {
    foo();
  }

and

  if (cond)
    foo();
  if (cond)
  {
    foo();
  }

and (GNU-style indentation)

  if (cond)
    foo();
  if (cond)
    {
      foo();
    }

I find the latter adequate, even though there are 2 spaces at each
level.

A higher number of spaces would be an issue if there are many nested
loops and if-tests, in particular if the lines are expected to fit in
80 columns (which would be a good idea, but this is not currently the
case in Mutt's code).

For large functions, editors should probably offer visual aids,
e.g. in the space taken by the indentation.

>   - In that same vein, more K&R, less GNU.  FWIW I think the perfect
>     style is W. Richard Stevens, Advanced Programming in the Unix
>     Environment.  (He uses ts=8 but it only really works if you're
>     VERY conscientious about writing small, well-factored functions or
>     aren't averse to very long lines.)

But if the functions are small, you do not need that many spaces
to distinguish between indentation levels.

>     GNU is an abomination,

I disagree.

>     which is why you pretty much never see it outside GNU projects
>     or projects of MIT grads... Pretty much never in books.
> 
>   - sizeof IS NOT A FUNCTION[*]. Do not format it like one, i.e. use:
>      ✓ sizeof varname        // no, doesn't need parens
>      ✓ sizeof (type name)    // parens needed, but not a function call!
>      ✓ struct foo *x; size_t s = sizeof *x; // doesn't need parens or to be 
> initialized/non-null!

But this can be error-prone. For instance,

  sizeof i + j

could be misread (specially if the minimum number of spaces are used:
sizeof i+j), and while

  sizeof -(int) i

is accepted,

  sizeof (int) i

isn't.

-- 
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Reply via email to