Hacker News new | ask | show | jobs
by phkahler 3077 days ago
return x >= "A"; // ascii A

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

4 comments

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.
(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.

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

See, here's where you are wrong.

  ASCII_A = "A"

  alphas = ["Α", "А", "Ꭺ", "ᗅ", "ꓮ", "A", "𐊠", "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.
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?
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.
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.

Be careful with your quotes (depending on which pseudo-language this is.)
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.
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.