4 ms·

Mmm... ageAlertThresholdHours = 24 + // backup interval 2 + // approx backup duration 2; // "w

Mmm... ageAlertThresholdHours = 24 + // backup interval 2 + // approx backup duration 2; // "wiggle room" No static assert needed, no need to pre-compute the total the first time, and no need to use identifiers like `approxBackupDurationHours`, the cognitive override about the possibility of colliding with other stuff that's in scope, or the superfluous/verbose variable declaration preamble.

feffe 10mo ago
I'm a believer in restricting the scope of definitions as much as possible, and like programming languages that allows creating local bindings for creating another. For example: local val backupIntervalHours = 24 val approxBackupDurationHours = 2 val wiggleRoomHours = 2 in val ageAlertThresholdHours = backupIntervalHours + approxBackupDurationHours + wiggleRoomHours end Then it's easier to document what components a constant is composed of using code without introducing unnecessary bindings in the scope of the relevant variable. Sure constants are just data, but the first questions that pops into my head when seeing something in unfamiliar code is "What is the purpose of this?", and the smaller the scope, the faster it can be discarded.
- zephen 10mo ago
  Mentally discarding a name still takes some amount of effort, even if local. I often write things the way you have done it, for the simple reason that, when writing the code, maybe I feel that I might have more than one use for the constant, and I'm used to thinking algebraically. Except, that I might make them global, at the top of a module. Why? Because they encode assumptions that might be useful to know at a glance. And I probably wouldn't go back and remove the constants once they were named. But I also have no problem with unnamed but commented constants like the ones in the comment you responded to.
- deleted 10mo ago
  [deleted]

feffe 10mo ago

I'm a believer in restricting the scope of definitions as much as possible, and like programming languages that allows creating local bindings for creating another. For example: local val backupIntervalHours = 24 val approxBackupDurationHours = 2 val wiggleRoomHours = 2 in val ageAlertThresholdHours = backupIntervalHours + approxBackupDurationHours + wiggleRoomHours end Then it's easier to document what components a constant is composed of using code without introducing unnecessary bindings in the scope of the relevant variable. Sure constants are just data, but the first questions that pops into my head when seeing something in unfamiliar code is "What is the purpose of this?", and the smaller the scope, the faster it can be discarded.

zephen 10mo ago
Mentally discarding a name still takes some amount of effort, even if local. I often write things the way you have done it, for the simple reason that, when writing the code, maybe I feel that I might have more than one use for the constant, and I'm used to thinking algebraically. Except, that I might make them global, at the top of a module. Why? Because they encode assumptions that might be useful to know at a glance. And I probably wouldn't go back and remove the constants once they were named. But I also have no problem with unnamed but commented constants like the ones in the comment you responded to.
deleted 10mo ago
[deleted]