Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

> Name constants based on their role, not their values. If a constant does not have a role apart from its value, then it is unnecessary to define it as a constant.

This breaks the linter in most cases because "magic numbers". Like having to declare a constant for the number of cents in a euro/dollar.

I think Google are right in this case, and linters need to be smarter.

View on HN

> 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.)

Yeah 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

More 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.

How 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.

Tell 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

ok, 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.

Reply on news.ycombinator.com