5 ms·

When you introduce a typo in a literal you will typically realise at runtime. Referencing a non-existing field won’t make it through compile time. I honestly do

When you introduce a typo in a literal you will typically realise at runtime. Referencing a non-existing field won’t make it through compile time. I honestly don’t see the problem with this approach. I would choose better (semantic) names though.

mojuba 4y ago
You shouldn't introduce a typo in the int literal "1" or even in the word "https". It should be in your manual memory.
- wruza 4y ago
  Some say it should be in a test.
  - mojuba 4y ago
    assert(INT_1 == 1); Gotcha.
    - zelphirkalt 4y ago
      What? You are going to use a global state for this? No, no, no! You ought to put that in a class ... class MyBetterrrrInteger(MyCustomNumberClass) implements ICalculatable { public static MyBetterrrrInteger(OtherIntegerClass num) { ... // oh did I forget to add generics to the mix? damn. } ... }
- chrsig 4y ago
  my issue is with it being named INT_1. If it were a constant with some meaning, I'd be accepting of it. As is, the only way I'd approve of it is if it was required to have the value be addressable. I'm not sure how often of a concern that is in java, but in Go for example, from ~1.3 to somewhat recently sticking an integer in a interface would cause a small allocation to hold the integer. By having it stored as a variable (you can't take the address of a constant in go) one could elide the allocation by storing the address of the variable in the interface instead of it's value. Of course now go will automatically do that for small values (N < 256). That's a pretty niche use, but it does exist. I'll assume it's not novel, and there are other, perhaps similar use cases for having a symbol instead of using the literal. wrt https: Yeah, it should be in muscle memory, but humans make mistakes, fat fingering is a thing. Using a symbol can give you a compilation time check. Of course, you may typo the symbol and have the exact same problem. The ability to compare by address actually applies more to strings though, since you can check the address & length for equality rather than having to do a full comparison of the string. This may or may not be an issue in any given language/implementation based on a variety of reasons (string interning, multiple definitions of a literal due to runtime/dynamic loading).
- hiq 4y ago
  I don't know if people should but people definitely do. When I review code, if a constant is inlined in several places (e.g. "https" is used instead of `PROTOCOL = "https"`), I have to check at every place that there's no typo. With a constant I just have to check once.

mojuba 4y ago

You shouldn't introduce a typo in the int literal "1" or even in the word "https". It should be in your manual memory.

wruza 4y ago
Some say it should be in a test.
- mojuba 4y ago
  assert(INT_1 == 1); Gotcha.
  - zelphirkalt 4y ago
    What? You are going to use a global state for this? No, no, no! You ought to put that in a class ... class MyBetterrrrInteger(MyCustomNumberClass) implements ICalculatable { public static MyBetterrrrInteger(OtherIntegerClass num) { ... // oh did I forget to add generics to the mix? damn. } ... }
chrsig 4y ago
my issue is with it being named INT_1. If it were a constant with some meaning, I'd be accepting of it. As is, the only way I'd approve of it is if it was required to have the value be addressable. I'm not sure how often of a concern that is in java, but in Go for example, from ~1.3 to somewhat recently sticking an integer in a interface would cause a small allocation to hold the integer. By having it stored as a variable (you can't take the address of a constant in go) one could elide the allocation by storing the address of the variable in the interface instead of it's value. Of course now go will automatically do that for small values (N < 256). That's a pretty niche use, but it does exist. I'll assume it's not novel, and there are other, perhaps similar use cases for having a symbol instead of using the literal. wrt https: Yeah, it should be in muscle memory, but humans make mistakes, fat fingering is a thing. Using a symbol can give you a compilation time check. Of course, you may typo the symbol and have the exact same problem. The ability to compare by address actually applies more to strings though, since you can check the address & length for equality rather than having to do a full comparison of the string. This may or may not be an issue in any given language/implementation based on a variety of reasons (string interning, multiple definitions of a literal due to runtime/dynamic loading).
hiq 4y ago
I don't know if people should but people definitely do. When I review code, if a constant is inlined in several places (e.g. "https" is used instead of `PROTOCOL = "https"`), I have to check at every place that there's no typo. With a constant I just have to check once.