What in the world is this inconsistent and bizarre spacing around brackets? I literally thought it was a new syntactical construct in C when my eyes first landed on it!

  cl_options [next_opt_idx].neg_index == opt_idx

  old_decoded_options[i].errors & ~CL_ERR_WRONG_LANG

and the parentheses too... why in the world do they do this?

  set_option (opts, (generated_p ? NULL : opts_set),
		opt_index, value, arg, kind, loc, dc);

GCC works quite well in practice and I don’t care much about a couple of extra/missing spaces in its source code. The answer to your question is probably “because the software has been developed for decades by thousands of unrelated people”.

Personally, I don’t write code like this, because I spam “autoformat” hotkey in the IDE :-)

Once upon a time, programmers didn't have IDE's, Emacs, or even text editors. I'd been programming for seven or eight years before Bill Joy created vi. Each programmer and each program had its own style.

Often, a program's layout reflected the programmer's inner thoughts as he or she worked through the creation of the code. Expressions were written like a mathematician might write, with spacing and bracketing reflecting some way of thinking about the grouping of the abstractions at hand.

This is just a random routine, written around 1975, from Niklaus Wirth's PL/0 compiler for Pascal, the programming language that he created. The indenting is wild by contemporary standards:

    procedure getch;
    begin if cc = ll then
       begin if eof(input) then
                  begin write(' program incomplete'); goto 99
                  end;
          ll := 0; cc := 0; write(cx: 5,' ');
          while not eoln(input) do
             begin ll := ll+1; read(ch); write(ch); line[ll]:=ch
             end;
          writeln; readln; ll := ll + 1; line[ll] := ' ';
       end;
       cc := cc+1; ch := line[cc]
    end {getch};

Early C code too, even in the Unix kernel, was often dense and hard to understand (the kernel was under 10,000 lines back then). See Lions' Commentary [2]. Here's a small function, setfs(), line 7167 of the system 6 Unix kernel in Lion's book. In particular note the lack of indention under the for loop:

    setfs(dev)
    {
       register struct mount *p;
       register char *n1, *n2;
      
       for(p = &mount[0]; p < &mount[NMOUNT]; p++)
       if(p->m_bufp != NULL && p->m_dev == dev) {
               p = p->m_bufp->b_addr;
               n1 = p->s_nfree;
               n2 = p->s_ninode;
               if(n1 > 100 || n2 > 100) {
                       prdev("bad count, dev);
                       p->s_nfree = 0;
                       p->s_ninode = 0;
               }
               return(p);
       }
       panic("no fs");
    }

It seems obvious now that standard and consistent formatting make programs easier to understand. Why did we old timers do that to ourselves? First, short programs were easier to keypunch or enter via a teletype machine. Second, we had a plenty of time to study our code. Turn around time for a compilation, from submission to printed listing, could take 30 minutes to 12 hours.

[1] http://pascal.hansotten.com/niklaus-wirth/pl0/

[2] John Lions, Lion's Commentary on Unix 6th Edition with Source Code. https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980...

>Often, a program's layout reflected the programmer's inner thoughts

And often it reflects the programmer's inner carelessness and disrespect for other programmers who have to deal with their code.