Hacker News Reader

Comment by bluGill | Hacker News Reader

Do you not know the conventions of your project? Doesn't your project have a convention that all time is in ms (second, weeks...)?

If your project doesn't have that convention such that everyone knows than the code should be

timeMs++;

You may also have a time type and so you can use your IDE to examine the type.

View on HN

I agree that the time unit should be in the variable name. The code itself should do a good job of explaining "what" is happening, but you generally need comments to explain "why" this code exists. Why is the test advancing the time, and why are we advancing the time at this line of the test?

    networkTimeMs++; // Callback occurs after timeout

    timeSec++; // Advance time to check whether dependent properties update

    utcTime++; // Leap second, DON'T advance ntpTime

> I agree that the time unit should be in the variable name

Also a terrible solution!

The code suffers from primitive obsession. Unless you're in a code section that is known to have performance issues, use real types.

    time = time.plusMilliseconds(1);

In a performance language your "real types" aren't somehow more expensive and so you should only use the built-in primitives when they accurately reflect your intent. So I would write:

time += Duration::from_millis(1);

But I would expect that "time unit should be in the variable name" is a reasonable choice in a language which doesn't have this affordance, and I needn't care about performance because apparently the language doesn't either.

I also wonder why we've named this variable "time". Maybe we're a very abstract piece of software and so we know nothing more specific? I would prefer to name it e.g. "timeout" or "flight" or "exam_finishes" if we know why we care about this.

> Do you not know the conventions of your project?

I just started yesterday! No, I don't.

Reply on news.ycombinator.com