3 ms·

Depends on the size of your codebase and how many people work on it. Once you have 20 years of code written full time by 200 developers in your monolith, findin

Depends on the size of your codebase and how many people work on it. Once you have 20 years of code written full time by 200 developers in your monolith, finding the constants file out of 400 different subsystem's constant files for a given subsystem that you've never seen before can become a legitimate and challenging pain.

maxbond 4y ago
Totally true. I don't know if IDEs commonly have a feature like, "find this value, regardless of how it's expressed" (even better yet, fuzzily, to catch typos), but I think that's the proper general solution. It's a good idea to consider a constants file earlyish, while everything still fits in your head. I'd say in the case of such a sprawling system, make a constants module, and it can have different files for different topics. But keep them all together. Code style is an engineering tool you can use to prevent problems. But I do understand this is cold comfort for those working on systems where the decision around this were made 15 years ago, and there's no possibility of refactoring the constants. That's quite annoying.
- CuriouslyC 4y ago
  Then you have a problem with having to update both the constants module and the service that depends on it to change the service, and you need to handle packaging and distributing the module. Maybe if you have a monorepo where those issues are moot...
  - maxbond 4y ago
    I didn't mean to suggest the constants module was a separate, reusable module, but a component of the same piece of software. By "module" here I meant "directory which can contain multiple importable files," so you could namespace your constants (constants/rfc_abcd.xyz, constants/customer_limits.xyz, etc). I'd rather copy-paste any reused constants to different projects to avoid coupling, unless there was some kind of compelling domain/project specific reason.
- ludston 4y ago
  When your code-base reaches a certain size, you cease using the IDE to find code and instead start using specialized tools, such as Lucene indexes so that grepping through code takes seconds rather than minutes. One of the bads of this is that using regex over an index is O(n) in comparison to the O(log(n)) of a normal index lookup.
  - maxbond 4y ago
    Perhaps this special tooling can normalize numbers and other source code ambiguity.
    - ludston 4y ago
      It certainly seems possible to use a parser when building your index. It's a lot of work though.
CuriouslyC 4y ago
This so hard. A constant that replaces a magic number like 5 that is ungreppable, or a constant for a precise number like the physical constants - sure. A constant that replaces a number like 404 or 500 that you want to be able to easily grep across heterogenous code bases for? Pass.
- maxbond 4y ago
  Is that 500 the HTTP error or 500 the adhoc limit we put on the number of user uploads or a 500, representing half a kilobyte?
  - CuriouslyC 4y ago
    I'll take the momentary ambiguity in some cases (usually quickly resolved by line context and file name) over having to manually hunt down 5 different projects' inconsistently named constants to do 5 different greps any day of the week.

maxbond 4y ago

Totally true. I don't know if IDEs commonly have a feature like, "find this value, regardless of how it's expressed" (even better yet, fuzzily, to catch typos), but I think that's the proper general solution. It's a good idea to consider a constants file earlyish, while everything still fits in your head. I'd say in the case of such a sprawling system, make a constants module, and it can have different files for different topics. But keep them all together. Code style is an engineering tool you can use to prevent problems. But I do understand this is cold comfort for those working on systems where the decision around this were made 15 years ago, and there's no possibility of refactoring the constants. That's quite annoying.

CuriouslyC 4y ago
Then you have a problem with having to update both the constants module and the service that depends on it to change the service, and you need to handle packaging and distributing the module. Maybe if you have a monorepo where those issues are moot...
- maxbond 4y ago
  I didn't mean to suggest the constants module was a separate, reusable module, but a component of the same piece of software. By "module" here I meant "directory which can contain multiple importable files," so you could namespace your constants (constants/rfc_abcd.xyz, constants/customer_limits.xyz, etc). I'd rather copy-paste any reused constants to different projects to avoid coupling, unless there was some kind of compelling domain/project specific reason.
ludston 4y ago
When your code-base reaches a certain size, you cease using the IDE to find code and instead start using specialized tools, such as Lucene indexes so that grepping through code takes seconds rather than minutes. One of the bads of this is that using regex over an index is O(n) in comparison to the O(log(n)) of a normal index lookup.
- maxbond 4y ago
  Perhaps this special tooling can normalize numbers and other source code ambiguity.
  - ludston 4y ago
    It certainly seems possible to use a parser when building your index. It's a lot of work though.

CuriouslyC 4y ago

This so hard. A constant that replaces a magic number like 5 that is ungreppable, or a constant for a precise number like the physical constants - sure. A constant that replaces a number like 404 or 500 that you want to be able to easily grep across heterogenous code bases for? Pass.

maxbond 4y ago
Is that 500 the HTTP error or 500 the adhoc limit we put on the number of user uploads or a 500, representing half a kilobyte?
- CuriouslyC 4y ago
  I'll take the momentary ambiguity in some cases (usually quickly resolved by line context and file name) over having to manually hunt down 5 different projects' inconsistently named constants to do 5 different greps any day of the week.