4 ms·

I have to say, to reasonably experienced C programmers, this code should be pretty clear. If you need that whole paragraph to understand (* ++argv)[0], you migh

I have to say, to reasonably experienced C programmers, this code should be pretty clear. If you need that whole paragraph to understand (* ++argv)[0], you might be an awesome programmer, but you're not yet a reasonably experienced C programmer. ;) I do think this is even more concise than they would have written in maintained code. In particular, I believe the missing {}'s for the 'while' and 'for' loops whouldn't have been left away, but I might be mistaken. Compare, for example, with this gem: https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html https://www.cs.princeton.edu/courses/archive/spr09/cos333/be... (submitted as https://news.ycombinator.com/item?id=5672875 https://news.ycombinator.com/item?id=5672875 some time ago) There Kernighan talks about a piece of code written by Rob Pike for inclusion in a different book; the code was written to be as small as possible while still including some useful functionality. In particular, Pike made well-considered choices about which functionality to include and which to exclude, but there are also some of those expressions that will not be completely transparent to the beginner C programmer. But the goal was writing short code, and clarity came secondary, but also emerged partly as a result of the first.

vultour 9y ago
I am not a C programmer, nor a veteran in any other language and this code was pretty clear.
bsder 9y ago
> If you need that whole paragraph to understand (* ++argv)[0], you might be an awesome programmer, but you're not yet a reasonably experienced C programmer. ;) Lines like that have far too much information density for my old brain, anymore. Things that went through my poor brain: "Why pre-inc/decrement? Why the +1 on the for? Did he actually get the precedence of the operators correct? Okay, it looks like argc and argv will be mangled if you actually want to do anything else with them. I see comparing to '\0' with no count limit--is there a buffer overrun lurking here?. Does that error handling actually work--that loop can't exit with that condition unless the second clause does something. And that was like--30 seconds? I'd assign argc and argv to something else so if I need them later for something they are in their original state. I'd give myself a variable that points to each individual argv on each iteration, and I'd call it something. I'd make the error handling more explicit so if I had to add another case later I wouldn't have to rack my brain about whether the error gets handled. Etc. Apparently I've become an inflexible, washed-up, old fart because I just don't enjoy writing C code with that kind of puzzle-like quality anymore.
- SomeHacker44 9y ago
  I feel an upvote is insufficient. An explicit thank you is necessary too.
- contras1970 9y ago
  i disagree with the sentiment and preferences expressed in your comment. the code on display is at the sweet spot of complexity given the scope of task at hand. your preferences might lead to code with lower complexity of any given expression, but there would be a higher number of expressions, higher number of statements, and higher number of names. that would mean higher complexity of the full code. should we ban multiplication on the basis that X times Y is the same as X plus X plus X...? > Why pre-inc/decrement? as opposed to what? nothing? clearly, the code needs to advance the iterators before dereferencing. > Why the +1 on the for? because it's interested in the option name as opposed to the leading dash: argv[0][0] is '-' (see the while above), the switch is looking at argv[0][1]. > Did he actually get the precedence of the operators correct? not sure what this is about, the only involved expression has explicit parentheses (out of necessity). > Okay, it looks like argc and argv will be mangled if you actually want to do anything else with them. yes... and? mutating a local int and a local pointer is bad? how would you go about this without mutating an iterator? > I see comparing to '\0' with no count limit--is there a buffer overrun lurking here? nope, it's an array of null-terminated strings. > Does that error handling actually work--that loop can't exit with that condition unless the second clause does something. i do not understand what you're pointing at here. > I'd assign argc and argv to something else so if I need them later for something they are in their original state. consider they're already local names, and YAGNI. do alias them if you need them later, not because you might one day. > I'd give myself a variable that points to each individual argv on each iteration, and I'd call it something. you would give yourself a possible bug and an obligation to keep the two things in sync. > I'd make the error handling more explicit so if I had to add another case later I wouldn't have to rack my brain about whether the error gets handled. what is more explicit than printf("Illegal option %c\n", *s); ? i'd really love to see your preferred version of the snippet from TFA. i posit it'd be two to three times as long, and its total complexity would be similarly increased.
  - 9y ago
pjmlp 9y ago
I can easily understand the code on the article, but other than the "gee look how cool!" factor, I never write such kind of code in production, as I take a few seconds to think about who might have to maintain it.
mveety 9y ago
> I do think this is even more concise than they would have written in maintained code. In particular, I believe the missing {}'s for the 'while' and 'for' loops wouldn't have been left away, but I might be mistaken. Well it depends a bit. Plan 9 is written very much in this style, but its easy to maintain because it has rules on when to omit things like braces or parens. You learn the rules pretty quickly (or read rob pike's paper) and after reading and using it a bit will make sense and you won't think about it. I would imagine if you just had someone in the group that wrote like this and the rest of you weren't used to it or the rules were applied inconsistently it would be a huge pain to actually deal with. What matters for all styles is that everyone has rules they agree with and actually follow them.
yakitori 9y ago
> If you need that whole paragraph to understand (* ++argv)[0], you might be an awesome programmer, but you're not yet a reasonably experienced C programmer. ;) That's the beauty of C. It can both amaze and terrify you at the same time. It's the programming equivalent of Philippe Petit. It's walking on a tight rope between the twin towers without a parachute or safety net. If anyone here enjoys awe and terror of C, look through the ioccc submissions. https://www.ioccc.org/winners.html https://www.ioccc.org/winners.html

vultour 9y ago

I am not a C programmer, nor a veteran in any other language and this code was pretty clear.

bsder 9y ago

> If you need that whole paragraph to understand (* ++argv)[0], you might be an awesome programmer, but you're not yet a reasonably experienced C programmer. ;) Lines like that have far too much information density for my old brain, anymore. Things that went through my poor brain: "Why pre-inc/decrement? Why the +1 on the for? Did he actually get the precedence of the operators correct? Okay, it looks like argc and argv will be mangled if you actually want to do anything else with them. I see comparing to '\0' with no count limit--is there a buffer overrun lurking here?. Does that error handling actually work--that loop can't exit with that condition unless the second clause does something. And that was like--30 seconds? I'd assign argc and argv to something else so if I need them later for something they are in their original state. I'd give myself a variable that points to each individual argv on each iteration, and I'd call it something. I'd make the error handling more explicit so if I had to add another case later I wouldn't have to rack my brain about whether the error gets handled. Etc. Apparently I've become an inflexible, washed-up, old fart because I just don't enjoy writing C code with that kind of puzzle-like quality anymore.

SomeHacker44 9y ago
I feel an upvote is insufficient. An explicit thank you is necessary too.
contras1970 9y ago
i disagree with the sentiment and preferences expressed in your comment. the code on display is at the sweet spot of complexity given the scope of task at hand. your preferences might lead to code with lower complexity of any given expression, but there would be a higher number of expressions, higher number of statements, and higher number of names. that would mean higher complexity of the full code. should we ban multiplication on the basis that X times Y is the same as X plus X plus X...? > Why pre-inc/decrement? as opposed to what? nothing? clearly, the code needs to advance the iterators before dereferencing. > Why the +1 on the for? because it's interested in the option name as opposed to the leading dash: argv[0][0] is '-' (see the while above), the switch is looking at argv[0][1]. > Did he actually get the precedence of the operators correct? not sure what this is about, the only involved expression has explicit parentheses (out of necessity). > Okay, it looks like argc and argv will be mangled if you actually want to do anything else with them. yes... and? mutating a local int and a local pointer is bad? how would you go about this without mutating an iterator? > I see comparing to '\0' with no count limit--is there a buffer overrun lurking here? nope, it's an array of null-terminated strings. > Does that error handling actually work--that loop can't exit with that condition unless the second clause does something. i do not understand what you're pointing at here. > I'd assign argc and argv to something else so if I need them later for something they are in their original state. consider they're already local names, and YAGNI. do alias them if you need them later, not because you might one day. > I'd give myself a variable that points to each individual argv on each iteration, and I'd call it something. you would give yourself a possible bug and an obligation to keep the two things in sync. > I'd make the error handling more explicit so if I had to add another case later I wouldn't have to rack my brain about whether the error gets handled. what is more explicit than printf("Illegal option %c\n", *s); ? i'd really love to see your preferred version of the snippet from TFA. i posit it'd be two to three times as long, and its total complexity would be similarly increased.
- 9y ago

pjmlp 9y ago

I can easily understand the code on the article, but other than the "gee look how cool!" factor, I never write such kind of code in production, as I take a few seconds to think about who might have to maintain it.

mveety 9y ago

> I do think this is even more concise than they would have written in maintained code. In particular, I believe the missing {}'s for the 'while' and 'for' loops wouldn't have been left away, but I might be mistaken. Well it depends a bit. Plan 9 is written very much in this style, but its easy to maintain because it has rules on when to omit things like braces or parens. You learn the rules pretty quickly (or read rob pike's paper) and after reading and using it a bit will make sense and you won't think about it. I would imagine if you just had someone in the group that wrote like this and the rest of you weren't used to it or the rules were applied inconsistently it would be a huge pain to actually deal with. What matters for all styles is that everyone has rules they agree with and actually follow them.

yakitori 9y ago

> If you need that whole paragraph to understand (* ++argv)[0], you might be an awesome programmer, but you're not yet a reasonably experienced C programmer. ;) That's the beauty of C. It can both amaze and terrify you at the same time. It's the programming equivalent of Philippe Petit. It's walking on a tight rope between the twin towers without a parachute or safety net. If anyone here enjoys awe and terror of C, look through the ioccc submissions. https://www.ioccc.org/winners.html https://www.ioccc.org/winners.html