4 ms·
> Like having to declare a constant for the number of cents in a euro/dollar. I agree with your point, but this is a bad example. Naming these constant CentsIn
by xiaq 4y ago
> Like having to declare a constant for the number of cents in a euro/dollar.
I agree with your point, but this is a bad example. Naming these constant CentsInEuro and CentsInUSDollar is consistent with the style guide.
As silly these examples are in isolation (of course a cent is 1/100 of a euro or a dollar), if you are writing code that processes currencies beyond euro and dollars, you will quickly end up with (using Chinese Yuan as an example):
const (
JiaoInCNYuan = 10
FenInCNYuan = 100
...
)
At which point adding
const (
CentsInUSDollar = 100
CentsInEuro = 100
...
)
is not just reasonable but a good idea.
Additionally, suppose your code needs to deal with historical currencies, you'll most likely need:
const (
ShillingsInOldBritishPound = 20
PenceInOldBritishShilling = 12
...
)
This is also a good example that the knowledge that a cent is 1/100 of a dollar or euro is highly culture-dependent. A British programmer from as late as 1970 will tell you that it's silly to create constants for these: of course there are 20 shillings in a pound and 12 pence in a shilling, everyone knows that! (I also like to think that they'd assume that a "cent" is 100 dollars because that's what centum means in Latin, but it's probably highly unlikely for them to never know US dollars and cents.)
- tragomaskhalos 4y agoYeah maybe. I've worked on code where there were constants defined for minutes-in-hour, hours-in-day etc though, and that was just annoying; it's conceivable that our culture will one day decide that the Babylonians were idiots and we should use the French revolutionary clock instead, but I'll take my chances
- deleted 4y ago[deleted]
- count 4y agoMore realistically, software will run on other celestial bodies which have different time periods (e.g. the moon, mars, asteroids, etc.). For me, the use of those annoying constants is a form of mental relief: I don't have to remember why I'm dividing by 60 or 100 or whatever in this specific spot, it's written out in a way that reading it provides the context.
- randomswede 4y agoHow many seconds in an hour? Most of the time, 3600, occasionally 3601, and very rarely 3599. Hours in a day? Mostly 24, but 23 once a year ad 25 once a year. These all seem like good reasons to make then functions (taking a timestamp as a n argument) rather than mostly-correct constants. I swear, the more I learn about calendars and timekeeping, the more I realise I never ever want to deal with it.
- euroderf 4y agoTell the reader that this here code is prepared for leap years, leap seconds, leap hours: SecondsPerStandardHour = 3600 // or NormalHour or TypicalHour HoursPerStandardDay = 24 // or NormalDay, TypicalDay
- marcus_holmes 4y agook, fair point, bad example. But having to declare a constant for the number of percentage points in a unit is insane and needs to stop. Bad linter, bad.