3 ms·

Another reason is that by providing an identifier for this string literal, misspellings of it can be detected by the compiler whereas there is nothing tying sep

Another reason is that by providing an identifier for this string literal, misspellings of it can be detected by the compiler whereas there is nothing tying separate string literals together.

userbinator 6y ago
I can hardly imagine a case where you would misspell "select" and not notice it at some point, nor use it in more than one place (the keyword detector) in the parser.
- triyambakam 6y ago
  You'd be surprised...
- Townley 6y ago
  The pattern (which I employ only sometimes) is to have almost all literals defined in this way. Perhaps SELECT isn’t likely to be the word you misspell, but I’m a careless typist and make 10 typos a minute. Taking this added step helps your editor save you from yourself.
  - viraptor 6y ago
    Having standards like that and keeping them helps a lot. Next time you have a different keyword, you don't have to think "does it deserve a constant?" - all of them do. Similar to how linters stop you from overthinking indentation in specific cases, or some naming standards, and later rename/reformat-wars.
    - userbinator 6y ago
      all of them do. That's what leads to dogmatic cargo-culting. Good software is written by thinking about the circumstances and doing what makes the most sense, not by mindless rule-following that don't always make sense. I don't know why someone would be so worried about typos and introduce more verbosity and redundancy in the process; but then again, I don't use an IDE and I've never had this problem.
      - viraptor 6y ago
        I'm not sure you're really making the argument you think here... Good software may mean thinking about circumstances like "we're dealing with lots of text parsing and have seen bugs from typos in common keywords" and doing what makes most sense: "let's prevent those in the future, but using constants for keywords". It's only cargo culting if you don't know why you're doing something. Setting a rule so you don't have to debate something later is a valid solution and may still offset some redundancies introduced this way.
- throwaway894345 6y ago
  It’s one of the more common bugs in our office. Before we integrated a Python linter in our CI for a prototype project, we would see several such typo errors each week with a small team (and that was with symbols, not string literals).
  - userbinator 6y ago
    Python and a lot of the other dynamic languages are in a slightly different situation.
    - throwaway894345 6y ago
      The point is that if you can make typos in identifiers in (unlinted) Python then you can make typos in string literals in Go. In both cases, there is no static analysis to help you.

Another reason is that by providing an identifier for this string literal, misspellings of it can be detected by the compiler whereas there is nothing tying separate string literals together.

userbinator 6y ago

I can hardly imagine a case where you would misspell "select" and not notice it at some point, nor use it in more than one place (the keyword detector) in the parser.

triyambakam 6y ago
You'd be surprised...
Townley 6y ago
The pattern (which I employ only sometimes) is to have almost all literals defined in this way. Perhaps SELECT isn’t likely to be the word you misspell, but I’m a careless typist and make 10 typos a minute. Taking this added step helps your editor save you from yourself.
- viraptor 6y ago
  Having standards like that and keeping them helps a lot. Next time you have a different keyword, you don't have to think "does it deserve a constant?" - all of them do. Similar to how linters stop you from overthinking indentation in specific cases, or some naming standards, and later rename/reformat-wars.
  - userbinator 6y ago
    all of them do. That's what leads to dogmatic cargo-culting. Good software is written by thinking about the circumstances and doing what makes the most sense, not by mindless rule-following that don't always make sense. I don't know why someone would be so worried about typos and introduce more verbosity and redundancy in the process; but then again, I don't use an IDE and I've never had this problem.
    - viraptor 6y ago
      I'm not sure you're really making the argument you think here... Good software may mean thinking about circumstances like "we're dealing with lots of text parsing and have seen bugs from typos in common keywords" and doing what makes most sense: "let's prevent those in the future, but using constants for keywords". It's only cargo culting if you don't know why you're doing something. Setting a rule so you don't have to debate something later is a valid solution and may still offset some redundancies introduced this way.
throwaway894345 6y ago
It’s one of the more common bugs in our office. Before we integrated a Python linter in our CI for a prototype project, we would see several such typo errors each week with a small team (and that was with symbols, not string literals).
- userbinator 6y ago
  Python and a lot of the other dynamic languages are in a slightly different situation.
  - throwaway894345 6y ago
    The point is that if you can make typos in identifiers in (unlinted) Python then you can make typos in string literals in Go. In both cases, there is no static analysis to help you.