Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

191–200 of 327 posts

Re: Please do not attempt to simplify this code

#191

Post by zzo38computer »

wavemode wrote: post #98

Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in. Maybe the disconnect her…

I looked through some parts of it, and it look like to me that there is many redundant stuff in many if/else blocks.

Re: Please do not attempt to simplify this code

#192

Post by sqeaky »

daemonologist wrote: post #88
dpedu wrote: post #72

Earlier quoted context omitted.

> Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. What exactly do they mean by this? If each of the 3 versions had exactly one bug, isn't this just a weird way of saying the first 2 fixes either didn't work or introduced a new bug?

Or maybe between one version and the next they only found one bug (there may have been bugs in the first version which weren't fixed until the third or later) - this seems more plausible to me since it's... rather difficult to count bugs until after you know about them. Of course now the greatness of the feat depends on how much testing there was between versions, but given that it was the shuttle there was probably…

And then we find a new category of bug, consider how we ran millions of different programs for many billions of CPU hours on all of our x86 CPUs before we learned about Spectre and meltdown.

Re: Please do not attempt to simplify this code

#193

Post by sqeaky »

chgs wrote: post #94
whalesalad wrote: post #6

Earlier quoted context omitted.

Well over 100 successful missions carrying a bunch of people and gear up into outer space and then bringing them back home. I hold it in a good light now, and will likely continue to feel that way. As far as human progress and net good, it was a success.

100 success and 2 failures. About a 1.6% failure rate from memory. That’s not a great record. Sure it’s a complex field, and it’s not as dangerous as say being US President, but a failure rate of >1% is not something to write home about.

I encourage you to build a more reliable space plane. Please link me to your blog and I will read your updates daily.

Re: Please do not attempt to simplify this code

#194

Post by kmoser »

marcus_holmes wrote: post #162
dskrvk wrote: post #137

Earlier quoted context omitted.

But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.

Comments (should) explain the "why" not the "what". The "why" doesn't go out of date, even if the "what" does.

Generalizations like that are theoretical, and don't always align with reality. There's nothing wrong with comments summarizing the "what", and in fact doing so is a good thing because it can describe anything from the intention of the code to the business logic. "This function merges array X with array Y, converting all the keys to lowercase because they will be used later by foo()."

The "why" can go out of date, e.g. "do X before Y because [specific thing in Y] is dependent on [specific thing in X]". If you rewrite Y to no longer be dependent on X, the comment is now out of date.

The reality is that any comment can go out of date at any time if the code it describes changes enough. But that's really no excuse for failure to maintain comments. Sure, in reality code is messy and inconsistently written, not even counting comments. Comments are an essential parts of your codebase, and while they are used exclusively by humans, that doesn't mean they are any less worthy of being updated and cultivated.

Re: Please do not attempt to simplify this code

#195

Post by geuis »

Joined a new company recently. They kept telling me their codebase was a mess. Yet I've been finding it to be remarkably refreshing. There are extensive comments everywhere. Lots of white space (remember to let your code breathe). Existing linting policies are extensive and thorough. The code is well structured and remarkably easy to follow through where that does what. I think it helps that it's a very small team with maybe 5-6 people max over time. It's such a pleasure to explore the project while learning the system and starting to fix some small long term issues. Really, really nice.

Re: Please do not attempt to simplify this code

#196

Post by mercer »

CodeWriter23 wrote: post #100
dpedu wrote: post #72

Earlier quoted context omitted.

> Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. What exactly do they mean by this? If each of the 3 versions had exactly one bug, isn't this just a weird way of saying the first 2 fixes either didn't work or introduced a new bug?

Regressions are not implied by that statement. A bug doesn’t exist in the human realm until a human observes it.

heisenbugs

Re: Please do not attempt to simplify this code

#197

Post by throwaway2037 »

DSMan195276 wrote: post #141
mumblemumble wrote: post #115

Earlier quoted context omitted.

I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…

I agree to a point, but I would separate explicit code from excessive commenting. Explicit code is good because it lets you explain to the reader what you're actually trying to do. Excessive comments (or even comments in general) is less so because compiler cannot check them for correctness, if someone simply forgets to update a comment or writes it incorrectly then the only thing to potentially catch it is a code re…

Do you consider this example as "excessive commenting"?

Re: Please do not attempt to simplify this code

#198

Post by ianburrell »

akira2501 wrote: post #172
jerlam wrote: post #4

// KEEP THE SPACE SHUTTLE FLYING. I understand the intent, but it is a bit funny that the comment references a system that is no longer operational due to its poor safety record. In ten years or so, will people even remember the Space Shuttle in a good light?

> due to its poor safety record. Per passenger mile traveled, the most common measure, it's one of the safest vehicles ever created and flown. > will people even remember the Space Shuttle in a good light? This is an honest question, since my childhood was squarely in the 1980s, but how can you possibly not? Are you so young that your only perspective of this program and all it's missions and accomplishments are pure…

Not even close to safest vehicle unless mean space vehicle. Space Shuttle was in orbit for 21k orbits and traveled 542 million miles. Which gives 28 deaths per billion miles.

Airliners are running 0.01 deaths per billion miles. Driving is 15 per billion miles. So it was worse than driving. Airliners beat it by 3 orders of magnitude. Which isn't surprising when US airliners travel distance of Space Shuttle in less than month.

Re: Please do not attempt to simplify this code

#199

Post by akira2501 »

ianburrell wrote: post #198
akira2501 wrote: post #172

Earlier quoted context omitted.

> due to its poor safety record. Per passenger mile traveled, the most common measure, it's one of the safest vehicles ever created and flown. > will people even remember the Space Shuttle in a good light? This is an honest question, since my childhood was squarely in the 1980s, but how can you possibly not? Are you so young that your only perspective of this program and all it's missions and accomplishments are pure…

Not even close to safest vehicle unless mean space vehicle. Space Shuttle was in orbit for 21k orbits and traveled 542 million miles. Which gives 28 deaths per billion miles. Airliners are running 0.01 deaths per billion miles. Driving is 15 per billion miles. So it was worse than driving. Airliners beat it by 3 orders of magnitude. Which isn't surprising when US airliners travel distance of Space Shuttle in less tha…

You are off by a factor of at least 5, because it's _passenger_ miles, not _vehicle_ miles. This is also why airlines are "so safe," because we put 300 people on them at a whack, if you were wondering where the "three orders of magnitude" actually comes from. It's still a man made machine being operated by humans.

So it's 5.1. Three times safer than driving. You might apocryphally conclude they were at greater risk taking the astro van to the pad.

Re: Please do not attempt to simplify this code

#200

Post by kmoser »

johnnyanmac wrote: post #73
ljm wrote: post #59

Earlier quoted context omitted.

There is no single canonical suite of best practices. There is also nothing harmful or unharmful about the length of a function or the lines of code in a file. Different languages have their opinions on how you should organise your code but none of them can claim to be ‘best practice’. Go as a language doesn’t favour code split across many small files.

It's all opinions and "best practice" isn't some objective single rule to uphold. But generally, best practices are "best" for a reason, some emperical. The machine usually won't care but the humans do. e.g. VS or Jetbrains will simply reject autocompletion if you make a file too big, and if you override the configuration it will slow down your entire IDE. So there is a "hard" soft-limit on how many lines you put in…

Assuming there is a compelling reason for a large file to begin with: with all due respect to VS Code and JetBrains, if the tools chokes because the file is too big, use a better tool.

As for long lines, there is sometimes value in consistently formatting things, even if it makes it somewhat harder to read because the lines run long. For example, it can make similar things all appear in the same column, so it's easy to visually scan down the column to see if something is amiss.

In any case, since soft wrapping has been available for ages, why do you feel the need to reformat the code at all in order to see long lines?

Post reply on HN