Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

Extract this into its own function and you basically have getopt() --- the POSIX version, not the rather more bloaty GNU version that has sometimes-unexpected behaviour (like reordering arguments).

If you like this sort of source code, I'd also recommend looking at the BSD standard utilities --- they have a similar simple and concise style.

Yet there's still one small simplification that can be made: the condition in the inner loop doesn't need "!= '\0'".

If there are many pure-binary options, then putting them in a bitflag is also an easy extension to the present code:

    char binopts[] = "abcdefg";
    char *opt;
    if(opt = strchr(binopts, *s))
     options |= 1 << (optidx - opt);
    else
     // put the switch(*s) here

Nowadays they just haul in the software weenies with their fancy objects and methods. Lost is the subtle art of manipulating arrays of pointers to strings of characters.

Indeed, compare with the "modern" way of doing it:

https://github.com/commandlineparser/commandline/tree/master...

...or something slightly simpler (because it's only one file!):

https://github.com/mono/mono/blob/master/mcs/class/Mono.Opti...

It may seem like an exaggeration, but in my experience working with C# and Java, code like that is the norm --- the core functionality is obscured by being scattered amongst a large amount of "fluff" and it's hard to get the whole picture of how it works because the flow jumps around so much. In contrast, the C code in this article can be understood by just staring at it for a little bit --- the entire functionality is contained within less than a dozen lines.

> compare with the "modern" way of doing it

The examples you’ve linked implement much larger set of functionality.

They de-serialize arguments into strongly typed values (validating arguments), validate against unknown commands/options, print various help messages, support globalization, support arrays in a single argument, and lots more.

Sure it’s overkill for a simple app with just a couple of options, but once you have sufficiently complex command line interface, this modern way becomes much simpler than what’s possible with C.

Compare with “old school” way of doing it: https://github.com/gcc-mirror/gcc/blob/master/gcc/opts.c https://github.com/gcc-mirror/gcc/blob/master/gcc/opts-globa... https://github.com/gcc-mirror/gcc/blob/master/gcc/opts-commo...

BTW that thing isn’t even localized, i.e. everything’s US English-only.

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.

>Yet there's still one small simplification that can be made: the condition in the inner loop doesn't need "!= '\0'".

I believe this would cause the newline not to be printed in the unknown command error, so it is necessary.

How? '\0' is the same value as 0 (only with a different type, which doesn't matter in this case), and if(x != 0) is the same as if(x).

> a different type

This is true in C++ but not in C.

Reply on news.ycombinator.com