8 ms·

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

by _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.
    - pantalaimon 8y ago
      C does not have that many concepts and they are usually pretty straightforward. Is it too much to ask for someone to look them up if they find one they are not familiar with?
      - mlthoughts2018 8y ago
        That seems like a completely backwards attitude. If you set out to write code to be maintainable and easily readable, you won’t think this way. Instead you’ll think, if I can write the code just slightly differently, slightly outside my own comfort zone or with less assumption about what burden should be on the reader, and it makes things much clearer for virtually no cost, why wouldn’t I? There’s no cost to me to write a separate assignment statement “i = i + 1” in many cases when I might otherwise write “i++”. The idea that it’s ok to put extraneous readership burden on the reader to nest “i++” in the middle of some other operator / indexing syntax / control flow logic is incompatible with writing good code. It has to start with prioritizing elementary clarity pedantically in cases when there’s no objective cost to disfavor it.
wycy 8y ago
While this is a common idiom, I do think it is bad from a maintainability standpoint. Let’s say in the future you need to change make a change, and the value of a becomes the elemental sum of the vectors b and c. a = b[i++] + c[i++] Errors like this are more avoidable by avoiding this sort of syntactical compression. a = b[i] + c[i] i += 1

by _kst_ 8y ago

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.
  - pantalaimon 8y ago
    C does not have that many concepts and they are usually pretty straightforward. Is it too much to ask for someone to look them up if they find one they are not familiar with?
    - mlthoughts2018 8y ago
      That seems like a completely backwards attitude. If you set out to write code to be maintainable and easily readable, you won’t think this way. Instead you’ll think, if I can write the code just slightly differently, slightly outside my own comfort zone or with less assumption about what burden should be on the reader, and it makes things much clearer for virtually no cost, why wouldn’t I? There’s no cost to me to write a separate assignment statement “i = i + 1” in many cases when I might otherwise write “i++”. The idea that it’s ok to put extraneous readership burden on the reader to nest “i++” in the middle of some other operator / indexing syntax / control flow logic is incompatible with writing good code. It has to start with prioritizing elementary clarity pedantically in cases when there’s no objective cost to disfavor it.

wycy 8y ago

While this is a common idiom, I do think it is bad from a maintainability standpoint. Let’s say in the future you need to change make a change, and the value of a becomes the elemental sum of the vectors b and c. a = b[i++] + c[i++] Errors like this are more avoidable by avoiding this sort of syntactical compression. a = b[i] + c[i] i += 1