5 ms·

Remember. Don't write stuff like a = b[i++] or a ^ c | d or use all these ambiguous C specific tricks that make it harder for everyone to read your code.

userbinator 8y ago
Neither of those are hard to understand if you know C. Write C like it's C, not like it's some other language. Edit: the first example is clearly stepping through values in an array, and the other is flipping some bits and setting others... what's hard to understand about that?
- _kst_ 8y ago
  Does a ^ c | d mean (a ^ c) | d or a ^ (c | d) ? The answer is unambiguous, and can easily be found by consulting the standard or any decent reference, but I've been using C for decades and I couldn't reliably answer without looking it up. I dislike some overuse of parentheses, but in this case I'd definitely use them.
  - mlthoughts2018 8y ago
    It’s similar with a = b[i++] instead of a = b[i] i++ // or even better, // i = i + 1 // and unequivocally // rejecting any // compiler for which // it might matter. What you save in typed characters utterly means nothing compared to the clarity of separating the two operations (especially side-effectful operations).
    - _kst_ 8y ago
      I humbly disagree on that point. a = b[i++] is certainly unambiguous to the compiler, but unlike the other example it should be unambiguous to the reader as well, assuming the reader is reasonably familiar with C. i++ yields the unmodified value of i, and as a side effect causes i to be incremented. There are no other references to i within the expression, so it doesn't matter when i is incremented. It's a common idiom for stepping through the elements of an array. If you're going to be reading C code, you have to be familiar with certain idioms that might be unfamiliar to someone who doesn't know C. I would certainly reject any compiler for which these: a = b[i++]; a = b[i]; i++; a = b[i]; i = i + 1; are not equivalent, since the language requires them to be. But I find the first more readable.
      - mlthoughts2018 8y ago
        This is the classic mistake of thinking that whatever familiarity of the standards or language quirks are “ubiquitous” in your mind somehow ought to be acceptable as standards for assumptions about what other people, people who may never have written a line of C code before, are going to think while reading. As a writer, whether of code or natural language, you are responsible for the thought patterns your writing actually induces in the mind of the reader, the practical side effect of someone reading your code, and emphatically not whatever you intended them to think. In this sense your defense of b[i++] just fails. It has nothing whatsoever to do with uniquity of the known value of i++, because that is already assuming something (familiarity with C syntax) that is dangerously foolish to assume of a code reader. Especially when an effortless alternative exists (i = i + 1) that meets a much, much wider natural expectation about assignment and order of operations.
        macintux 8y ago
        I disagree somewhat. The i++ vs ++i behavior is a classic C idiom and something that any experienced C programmer should understand. The order of operations for bit operators is something only a subset of experienced programmers would likely have memorized. I’m not advocating for using it, per se, but I’d be shocked to find any C programmer who knows the latter but not the former.
        mlthoughts2018 8y ago
        In my current job, I write production machine learning code often in Scala. I had never written a line of Scala before that, had no idea what the idioms were nor even what some of the inheritance and object privacy syntax meant. I read through mountains of legacy Scala code while working on my first several projects, and have assisted dozens of other new developers (most of whom also have never once read or thought about Scala previously). The assumptions people made in that codebase still give me nightmares, mostly over how foolish and lazy they are in little ways, little unexplained “self documented” things that create multi-hour stumbling blocks but which could have been written in a more “elementary” style in the first place (without sacrificing any necessary language features). When I see things like, “any C programmer should know ...” I just slap my head in stupor. It just misses the point entirely. It’s of zero importance whatsoever to write code in language X in a style that benefits mostly only “people who know language X.” Pretend you’re writing the code for a freshman intern who will look at it in 5 or 10 years with no prior knowledge of the language it’s written in, and now you’re in the correct ballpark for how to write professional software.
  - userbinator 8y ago
    but I've been using C for decades Chances are you haven't been using C much for hardware/low-level stuff, because the ^ operator is seldom seen outside of that context. On the other hand, the precedence of & and | (and likewise, && and ||) should be general knowledge: the former has the higher precedence, in analogy with multiplication vs addition.
huhtenberg 8y ago
> a = b[i++] You can't be serious. How is this ambiguous in the slightest? Assuming that you actually know some rudimentary C.
- gamma-male 8y ago
  Because a = b[++i] means something different. It's a dense and unecessary shortcut.
  - userbinator 8y ago
    At the risk of being downvoted again (for which I don't much care, but it does say much about the mindset...), is it so very much unreasonable to ask of programmers using a language, and more importantly a language they will be using very frequently, to just learn the language!?!? The amount of dumbing-down that I've seen happen to programming is already beyond ridiculous. You should definitely look at APL, Lisp, or some of the other more expressive languages out there if you think anything beyond the equivalent of glorified Asm (one statement per line, one operation per statement, one use per variable...) is "dense and unecessary[sic] shortcut". I think this a relevant article to start understanding the opposite point of view: https://news.ycombinator.com/item?id=13565743 https://news.ycombinator.com/item?id=13565743
    - rleigh 8y ago
      You're absolutely right that developers should know this stuff. But that's to some degree the wrong point to make. When considering the maintainability and correctness of the codebase, "clever" hacks are often not desirable. Nowadays, there's no performance gain to be had by indulging in such tricks; the optimiser will do the right thing for both cases. The problem for me here is not that it's "too complex", but that it's ambiguous even for experts with a casual glance. It makes perfect sense right now after you've written it, but months or years later, the person reading this while doing some maintenance or debugging might glance over and not see the subtlety of pre- vs post-increment while they are busy with other tasks and deadlines. It does make sense to avoid such pitfalls, where possible.
    - 8y ago
romeisendcoming 8y ago
WTF?

userbinator 8y ago

Neither of those are hard to understand if you know C. Write C like it's C, not like it's some other language. Edit: the first example is clearly stepping through values in an array, and the other is flipping some bits and setting others... what's hard to understand about that?

_kst_ 8y ago
Does a ^ c | d mean (a ^ c) | d or a ^ (c | d) ? The answer is unambiguous, and can easily be found by consulting the standard or any decent reference, but I've been using C for decades and I couldn't reliably answer without looking it up. I dislike some overuse of parentheses, but in this case I'd definitely use them.
- mlthoughts2018 8y ago
  It’s similar with a = b[i++] instead of a = b[i] i++ // or even better, // i = i + 1 // and unequivocally // rejecting any // compiler for which // it might matter. What you save in typed characters utterly means nothing compared to the clarity of separating the two operations (especially side-effectful operations).
  - _kst_ 8y ago
    I humbly disagree on that point. a = b[i++] is certainly unambiguous to the compiler, but unlike the other example it should be unambiguous to the reader as well, assuming the reader is reasonably familiar with C. i++ yields the unmodified value of i, and as a side effect causes i to be incremented. There are no other references to i within the expression, so it doesn't matter when i is incremented. It's a common idiom for stepping through the elements of an array. If you're going to be reading C code, you have to be familiar with certain idioms that might be unfamiliar to someone who doesn't know C. I would certainly reject any compiler for which these: a = b[i++]; a = b[i]; i++; a = b[i]; i = i + 1; are not equivalent, since the language requires them to be. But I find the first more readable.
    - mlthoughts2018 8y ago
      This is the classic mistake of thinking that whatever familiarity of the standards or language quirks are “ubiquitous” in your mind somehow ought to be acceptable as standards for assumptions about what other people, people who may never have written a line of C code before, are going to think while reading. As a writer, whether of code or natural language, you are responsible for the thought patterns your writing actually induces in the mind of the reader, the practical side effect of someone reading your code, and emphatically not whatever you intended them to think. In this sense your defense of b[i++] just fails. It has nothing whatsoever to do with uniquity of the known value of i++, because that is already assuming something (familiarity with C syntax) that is dangerously foolish to assume of a code reader. Especially when an effortless alternative exists (i = i + 1) that meets a much, much wider natural expectation about assignment and order of operations.
      - macintux 8y ago
        I disagree somewhat. The i++ vs ++i behavior is a classic C idiom and something that any experienced C programmer should understand. The order of operations for bit operators is something only a subset of experienced programmers would likely have memorized. I’m not advocating for using it, per se, but I’d be shocked to find any C programmer who knows the latter but not the former.
        mlthoughts2018 8y ago
        In my current job, I write production machine learning code often in Scala. I had never written a line of Scala before that, had no idea what the idioms were nor even what some of the inheritance and object privacy syntax meant. I read through mountains of legacy Scala code while working on my first several projects, and have assisted dozens of other new developers (most of whom also have never once read or thought about Scala previously). The assumptions people made in that codebase still give me nightmares, mostly over how foolish and lazy they are in little ways, little unexplained “self documented” things that create multi-hour stumbling blocks but which could have been written in a more “elementary” style in the first place (without sacrificing any necessary language features). When I see things like, “any C programmer should know ...” I just slap my head in stupor. It just misses the point entirely. It’s of zero importance whatsoever to write code in language X in a style that benefits mostly only “people who know language X.” Pretend you’re writing the code for a freshman intern who will look at it in 5 or 10 years with no prior knowledge of the language it’s written in, and now you’re in the correct ballpark for how to write professional software.
- userbinator 8y ago
  but I've been using C for decades Chances are you haven't been using C much for hardware/low-level stuff, because the ^ operator is seldom seen outside of that context. On the other hand, the precedence of & and | (and likewise, && and ||) should be general knowledge: the former has the higher precedence, in analogy with multiplication vs addition.

huhtenberg 8y ago

> a = b[i++] You can't be serious. How is this ambiguous in the slightest? Assuming that you actually know some rudimentary C.

gamma-male 8y ago
Because a = b[++i] means something different. It's a dense and unecessary shortcut.
- userbinator 8y ago
  At the risk of being downvoted again (for which I don't much care, but it does say much about the mindset...), is it so very much unreasonable to ask of programmers using a language, and more importantly a language they will be using very frequently, to just learn the language!?!? The amount of dumbing-down that I've seen happen to programming is already beyond ridiculous. You should definitely look at APL, Lisp, or some of the other more expressive languages out there if you think anything beyond the equivalent of glorified Asm (one statement per line, one operation per statement, one use per variable...) is "dense and unecessary[sic] shortcut". I think this a relevant article to start understanding the opposite point of view: https://news.ycombinator.com/item?id=13565743 https://news.ycombinator.com/item?id=13565743
  - rleigh 8y ago
    You're absolutely right that developers should know this stuff. But that's to some degree the wrong point to make. When considering the maintainability and correctness of the codebase, "clever" hacks are often not desirable. Nowadays, there's no performance gain to be had by indulging in such tricks; the optimiser will do the right thing for both cases. The problem for me here is not that it's "too complex", but that it's ambiguous even for experts with a casual glance. It makes perfect sense right now after you've written it, but months or years later, the person reading this while doing some maintenance or debugging might glance over and not see the subtlety of pre- vs post-increment while they are busy with other tasks and deadlines. It does make sense to avoid such pitfalls, where possible.
  - 8y ago

romeisendcoming 8y ago

WTF?