keydir = *++argv; if (!keydir) die_usage();
if (*x == 'v') { if (flagverbose >= 2) flagverbose = 3; else flagverbose = 2; continue; }
Value consistency above everything.
Honestly, I am not convinced that the peculiar if-style isn't actually helping readability and refactoring. Note, that a Apple-style "goto break" bug might be harder to construct, when your one-line if's look like this:
some_code;
if (something) die(message);
other_code;
some_code;
if (something)
die(message);
other_code;
You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't.
On a side note: your second example even seems to suggest that the authors made some effort at additional readability by refraining from using the ternary operator construct.
An awakening!
Is it really so terrible to have things compile quickly and without the usual ./configure nonsense? It seems there are an infinite number of ways an author can organise her project using ./configure; for every one I have to spend time figuring out what they have done.
One of my favourite aspects of djb's build approach (which is what is being used here) is that it's easier (than with the popular build systems) to change compiler and linker options and make static binaries: in most cases, simple edit the conf-* files. Thankfully, authors who use djb's approach usually do not vary much from the model. This means less time spent figuring out how things are organised.
I like (portable) open source software that compiles quickly and cleanly.
djb has continued to deliver on this point.
Nice to see someone discovering this build system for the first time.
djb's work, whether it's coding style or build system or something else, tends to differ from what is "popular".
The parent's comment is along the lines of: what is unfamiliar can appear more difficult, but after the adjustment it may actually appear easier than the prior alternative.
If you view the parent's comment in this light, then you will see that both the Linux kernel coding style and the GNU build system are very familiar for lots of folks.
If you are migrating to using tinyssh and other software that follow's djb's style for the first time, then you will no doubt have to "get used to it" and you might even perceive it as being difficult.
To be crystal clear, I'm not singling out the Linux kernel or the GNU build system. The GNU build system is but one example; the Linux kernel coding style is another.
I could make a lengthy list of "familiar", popular approaches that I could argue are inferior to djb's approach to the same task.
It's just my opinion. If you disagree, feel free to state your own opinion.
Because it's more readable.
Do
you
truly
find having
only a few
words per line
more
readable?
Does
it aid
with
comprehension?
I find having a high word density to be the most "readable", and it doesn't seem to matter whether it's C or English.
The TinySSH source code is small enough that I was able to read it in about 25 minutes and I learned about the SSH protocol along the way.
that being said,
breaking a sentence across multiple lines
does help with comprehension
when you break on clause boundaries.
To me, more code that you can get on a single screen/buffer, the better. My complaint is more about putting braces on a separate line all by themselves.
(Not that I would have written either line that way, mind you. But there's no real challenge understanding them.)