←back to thread

873 points belter | 1 comments | | HN request time: 0s | source
Show context
GuB-42 ◴[] No.42948407[source]
Just personal opinions, I guess, I agree with most, but here are some I disagree with:

- There is no pride in managing or understanding complexity

Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity.

- Java is a great language because it's boring

That is if you write Java the boring way. A lot of Java code (looking at you Spring) is everything but boring, and it is not fun either.

- Most programming should be done long before a single line of code is written

I went the opposite extreme. That is, if you are not writing code, you are not programming. If you are not writing code on your first day your are wasting time. It is a personal opinion, but the idea is that without doing something concrete, i.e. writing code, it is too easy to lose track of the reality, the reality being that in the end, you will have a program that runs on a machine. It doesn't mean you will have to keep that code.

- Formal modeling and analysis is an essential skill set

Maybe that explains our difference with regard to the last point. Given the opportunity, I prefer try stuff rather than formalize. It is not that formal modeling is useless, it is just less essential to me than experimentation. To quote Don Knuth out of context: "Beware of bugs in the above code; I have only proved it correct, not tried it." ;)

- You literally cannot add too many comments to test code (I challenge anyone to try)

time++; // increment time

replies(5): >>42948448 #>>42949655 #>>42949715 #>>42951149 #>>42963604 #
do_not_redeem ◴[] No.42949655[source]
> time++; // increment time

This isn't too many comments, it's a poor quality comment. Try:

time++; // advance 1 simulated second

replies(2): >>42949812 #>>42958980 #
bluGill ◴[] No.42949812[source]
What is wrong with

   time++;
That seem obvious enough to me without any comments.
replies(4): >>42950683 #>>42950807 #>>42956919 #>>42963696 #
smallerfish ◴[] No.42950683[source]
Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out?

When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.

replies(4): >>42951256 #>>42951334 #>>42952723 #>>42960176 #
bluGill ◴[] No.42951256[source]
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.

replies(2): >>42956357 #>>42956741 #
rovolo ◴[] No.42956357[source]
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
replies(1): >>42956777 #
stickfigure ◴[] No.42956777[source]
> 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);
replies(1): >>42962556 #
1. tialaramex ◴[] No.42962556[source]
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.