[coldtea]

>ASCII_A could be set incorrectly, or have a dumb type, and is more verbose anyway. By using the character directly, the code speaks its purpose.

I disagree. ASCII_A speaks it's purpose (we purposefully want an ASCII A stored here). And one can check the constant's definition, and immediately tell if it's correct. E.g.

  const ASCII_A = 'A' // correct

  const ASCII_A = 'E' // wrong

So:

  return x >= ASCII_A

tell us the intention of the code's author.

Whereas:

  return x >= ‘A’;

only tells us what the code does, which might nor might not be correct (and we have no way of knowing, without some other documentation).

So, by those two lines:

  const ASCII_A = 'E';
  (...)
  return x >= ASCII_A;

We know what the code is meant to do, AND that it does it wrongly (and thus, we know what to fix).

These line, on the other hand:

  return x >= ‘A’;

tells us nothing. Should it be 'A'? Should it be something else? We don't know.

[icebraining]

How do you know that it's the "E" that is wrong, and not the ASCII_A? Maybe it should be ASCII_E.

(If you say it's because it's written twice, well, that's only a valid clue if ASCII_E doesn't happen to be defined too.)

[coldtea]

>How do you know that it's the "E" that is wrong, and not the ASCII_A? Maybe it should be ASCII_E.

Ultimately you don't, but ASCII_A requires double the intentional actions to name it and have it also be 'A', whereas 'A' vs 'E' or whatever else is a much easier typo.

It's the whole idea behind NOT having magic values in your code. That is, that:

  if (temp > 212)

tells us much less than:

  if (temp > WATER_BOILING_TEMP)

and that we can more easily spot an error with:

  WATER_BOILING_TEMP = 275

than with:

  if (temp > 275)

[icebraining]

Ultimately you don't, but ASCII_A requires double the intentional actions to name it and have it also be 'A', whereas 'A' vs 'E' or whatever else is a much easier typo.

Unless, as I wrote after, you have both ASCII_A and ASCII_E declared, which wouldn't be surprising.

I don't find the "spot the error" argument to be very convincing; I still name stuff, but just for the semantic value.

[dragonwriter]

275°F is about right at a little over 3 bar.

Or 275°C at around 60 bar.

[phkahler]

return x >= "A"; // ascii A

Gets the whole message across in one line, as does using 65 with the comment.

[yesenadam]

Comments aren't so good - now you have 2 things to change when the program changes. In the real world, often the comment won't be updated and will become actively misleading/wrong/bad.

[robotresearcher]

(Ignoring the typo "A" != 'A')

return x >= 'A';

already and only means ascii A. Is there a C compiler anywhere where or likely in future where 'A' in C is NOT ascii A? The comment is redundant if correct, and could be wrong after an edit, so it has no value.

[coldtea]

>return x >= 'A'; already and only means ascii A.

See, here's where you are wrong.

  ASCII_A = "A"

  alphas = ["Α", "А", "Ꭺ", "ᗅ", "ꓮ", "Ａ", "𐊠", "A", "𝐀", "𝖠", "𝙰", "𝚨", "𝝖"]

  for c in alphas:
      print c == ASCII_A

Output?

  False
  False
  False
  False
  False
  False
  False
  True
  False
  False
  False
  False
  False

Several of the numerous possible utf-8 alphas. Those are not A in different fonts -- they are different unicode characters that look like A. And depending on your font they could look absolutely the same as plain ascii a (of which only one towards the middle of the list is). And depending on your locale and keyboard language settings, one of them could be as easy to click as the regular english A in ASCII.

[robotresearcher]

I deliberately used the character literal ‘A’ and not any of your UTF8 strings. I think you are mistaken to confuse a character with your strings. Is this wrong?

[coldtea]

You can have a unicode character literal -- and depending on the language there's no distinction between character and string (at the type level), a character is just a string of length 1.

[robotresearcher]

I was assuming C, where there is a difference.

int main() { printf( "%d %d\n", 'A', "A" ); return 0; }

produces: 65 197730221

since the value of string "A" is its base address.

[mannykannot]

Be careful with your quotes (depending on which pseudo-language this is.)

[coldtea]

Without the convenience of autocomplete and re-use in other places in the code, and with a comment that can always get out of sync with what the code does much easier than a named constant.

[phkahler]

My comment was a bit weak. Putting something more of a requirement or design intent in the comment is better. Having it all there can be better than a well described constant with a definition somewhere else. Sure, they could get out of sync but at least you'll be able to see the discrepancy right there on that line if you're looking. But to each their own.

[zb]

You must be one of those people who writes stuff like #define TWO 2