3 ms·

I think there's a difference between: 5 embedded in the code, and const int maxRetries = 5; at the top of a file. Both are still hardcoded, but there

by louthy 11y ago

I think there's a difference between: 5 embedded in the code, and const int maxRetries = 5; at the top of a file. Both are still hardcoded, but there's at least context for the number.

bryanlarsen 11y ago
I'd far rather have the 5 embedded in the code. It should be obvious from the code that the 5 is the number of retries, and it's often important to know at least the magnitude of the number when reading the code. Don't make me hunt for the number unless you have a good reason for doing so. If the name is required to understand the code, then putting your "const int maxRetries = 5;" in the code is better than a comment that says the same thing. Just don't put it at the top of the file. Put it on the line before you use it.
- reagency 11y ago
  Factoring out constants has a nice effect of turning your header into a sort of declarative program, a quick summary of the interesting behavior choices the program makes, a guide to understanding the program at a glance. With numRetries=5, you can see he program makes retries. Withjust 5, that fact is hidden away in a method parameter somewhere. And unless your IDE is ed+cat, there is no hunting needed to jump to a definition of a method. Having layers of generality makes code easier to read.
  - omaranto 11y ago
    ed + cat seems like an odd combination: why not use just ed (it has a print command, p)?
  - Eridrus 11y ago
    > And unless your IDE is ed+cat, there is no hunting needed to jump to a definition of a method. Having layers of generality makes code easier to read. I completely disagree; adding extra indirection/generality always makes your code harder to understand. Adding meaningful/intuitive abstractions makes it significantly easier though. My pet peeve is Java interfaces that only exist because you need to be able to mock the object in testing, but otherwise only have one real implementation. Especially when the name gives no indication that it's an interface, so you only find out after you pressed F3.
- codazoda 11y ago
  If you put the const declaration just before you use it and then you or someone else uses it somewhere else, you are going to have an even harder time finding it. If it needs a const, declare it at the top so I know where to look.
- georgeecollins 11y ago
  You say it should be obvious what a value embedded in code is. OK, but for one reason or another it often is not. So why not have your coding standard be name constants well at the top of the file or function. I think that is more consistently readable and reusable.
- steven2012 11y ago
  This is silly. If you don't have a single constant, you could have the situation where one piece of code had a maxRetry of 5, and another with a maxRetry of 2. Good luck trying to figure out why things are failing when they should retrying 5 times.
  - anthony_d 11y ago
    The problem is you might (sometimes should) have different retry counts depending on what you're retrying. So MAX_RETRY (or whatever) isn't actually that meaningful when you run into the constant. It might actually be misleading.
    - gknoy 11y ago
      This is solveable with extra verbosity. # no: MAX_FAILS = 3 MAX_RETRIES = 5 # yes: MAX_API_CONNECTION_RETRIES = 3 MAX_COMPLEX_GRAPH_SOLVING_RETRIES = 5 Apologies for terrible names, but the point is that you should name the constant different things, so that it's clear what __kinds__ of retries you are capping.
- zwieback 11y ago
  I think if you can't reliably find all occurrences of a value then it shouldn't be hardcoded - 6.022e23 is easier to find in a large source file than 5. If you work in a statically typed language with a decent IDE you can usually see the constant value just by hovering over the identifier. I'm guessing there are different tradeoffs in dynamically typed languages since the hardcoded number will also identify the type.
stinos 11y ago
I'm all for extracting constants, but not (always) to the top of the file: why not put them as close as possible to where they are used - especially for one time uses?
BurningFrog 11y ago
Naming and being at the top of the file are separate things. If it needs a name, name it where it's used! I think of the "no magic constants" as a primitive precursor to the DRY principle. It was a good approximation for its time, but now we know better.

by louthy 11y ago

I think there's a difference between: 5 embedded in the code, and const int maxRetries = 5; at the top of a file. Both are still hardcoded, but there's at least context for the number.

bryanlarsen 11y ago

I'd far rather have the 5 embedded in the code. It should be obvious from the code that the 5 is the number of retries, and it's often important to know at least the magnitude of the number when reading the code. Don't make me hunt for the number unless you have a good reason for doing so. If the name is required to understand the code, then putting your "const int maxRetries = 5;" in the code is better than a comment that says the same thing. Just don't put it at the top of the file. Put it on the line before you use it.

reagency 11y ago
Factoring out constants has a nice effect of turning your header into a sort of declarative program, a quick summary of the interesting behavior choices the program makes, a guide to understanding the program at a glance. With numRetries=5, you can see he program makes retries. Withjust 5, that fact is hidden away in a method parameter somewhere. And unless your IDE is ed+cat, there is no hunting needed to jump to a definition of a method. Having layers of generality makes code easier to read.
- omaranto 11y ago
  ed + cat seems like an odd combination: why not use just ed (it has a print command, p)?
- Eridrus 11y ago
  > And unless your IDE is ed+cat, there is no hunting needed to jump to a definition of a method. Having layers of generality makes code easier to read. I completely disagree; adding extra indirection/generality always makes your code harder to understand. Adding meaningful/intuitive abstractions makes it significantly easier though. My pet peeve is Java interfaces that only exist because you need to be able to mock the object in testing, but otherwise only have one real implementation. Especially when the name gives no indication that it's an interface, so you only find out after you pressed F3.
codazoda 11y ago
If you put the const declaration just before you use it and then you or someone else uses it somewhere else, you are going to have an even harder time finding it. If it needs a const, declare it at the top so I know where to look.
georgeecollins 11y ago
You say it should be obvious what a value embedded in code is. OK, but for one reason or another it often is not. So why not have your coding standard be name constants well at the top of the file or function. I think that is more consistently readable and reusable.
steven2012 11y ago
This is silly. If you don't have a single constant, you could have the situation where one piece of code had a maxRetry of 5, and another with a maxRetry of 2. Good luck trying to figure out why things are failing when they should retrying 5 times.
- anthony_d 11y ago
  The problem is you might (sometimes should) have different retry counts depending on what you're retrying. So MAX_RETRY (or whatever) isn't actually that meaningful when you run into the constant. It might actually be misleading.
  - gknoy 11y ago
    This is solveable with extra verbosity. # no: MAX_FAILS = 3 MAX_RETRIES = 5 # yes: MAX_API_CONNECTION_RETRIES = 3 MAX_COMPLEX_GRAPH_SOLVING_RETRIES = 5 Apologies for terrible names, but the point is that you should name the constant different things, so that it's clear what __kinds__ of retries you are capping.
zwieback 11y ago
I think if you can't reliably find all occurrences of a value then it shouldn't be hardcoded - 6.022e23 is easier to find in a large source file than 5. If you work in a statically typed language with a decent IDE you can usually see the constant value just by hovering over the identifier. I'm guessing there are different tradeoffs in dynamically typed languages since the hardcoded number will also identify the type.

stinos 11y ago

I'm all for extracting constants, but not (always) to the top of the file: why not put them as close as possible to where they are used - especially for one time uses?

BurningFrog 11y ago

Naming and being at the top of the file are separate things. If it needs a name, name it where it's used! I think of the "no magic constants" as a primitive precursor to the DRY principle. It was a good approximation for its time, but now we know better.