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

11–20 of 647 posts

Re: Please do not attempt to simplify this code

#11

Post by sl1ck731 »

startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

I think it indicates pride more than anything. If I write something that is just business as usual or commonplace my comments are pretty lacking. If it is something very interesting or that I am proud to have done, I usually write some very detailed comments. This probably correlates to better quality just because it was something I was interested in doing rather than shoveling code.

Re: Please do not attempt to simplify this code

#12

Post by existencebox »

startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

I think it's situationally useful. If I take the author of the OP code at their word, this is one of those situations.

Core, critical plumbing/logic at the kernel of business critical, long-lived applications, will be the source of my stress-dreams long into the twilight years of my life; in the form of a lack of documentation and a presence of organic growth.

To criticize myself quite bluntly: If the core code I worked on at work looked like this, I'd feel a great deal more comfortable in some of the changes/digging that inevitably arises.

I would never use it as an absolute metric; but I'd use the level of comfort e.g. a new dev feels when looking at something that might otherwise be a spiderweb and saying "Oh this makes sense" (As I do when looking at OP) as a north star for the most sensitive bits of logic.

Re: Please do not attempt to simplify this code

#13

Post by raverbashing »

Some code do require this style.

If the code is complicated, sometimes it's better to make it extra explicit than just relying on the reader's comprehension (including empty else blocks, for example)

Because in a nested A/B/C condition it is very easy to not notice what happens in the case where A v !B v C and/or why is it different from A v B v !C especially when some of those can't happen together (but then the code does "something" and "can't happen together" means "it will happen in that very weird case")

Re: Please do not attempt to simplify this code

#14

Post by munk-a »

This style of code with an emphasis on branch completeness is the biggest virtue Go gets from the lack of exceptions.

I personally dislike that style since that level of detail seems extraneous for normal tasks, but when you need to write code with absolute assurances like this then preventing the stack from being unwound without an explicit return (or panic, because some stuff is just terrible) is quite helpful to inspect and insure you have full coverage.

Re: Please do not attempt to simplify this code

#15

Post by spyspy »

startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

Long comments tend to scare me because they often detail some horrific hack that I'm going to have to deal with.

Re: Please do not attempt to simplify this code

#16

Post by dajonker »

"it became clear that we needed to ensure that every single condition was handled and accounted for in the code"

This is a feature of several (mostly functional) programming languages, e.g. Haskell. Fun to see that often people figure out that these types of concepts are a smart way to write your code. Too bad it usually means many people reinvent the wheel instead of learning about computer science history and other languages.

Re: Please do not attempt to simplify this code

#17

Post by lifeisstillgood »

Nice. At some point one rolls up your sleeves and says "right, this part is important and needs to work and I need to be sure I have got it right" At that point space shuttle style works pretty well (usually for me I am writing some security / control dispatch for the umpteenth time)

Re: Please do not attempt to simplify this code

#18

Post by zrail »

rossdavidh wrote: post #5

While I can understand the basic philosophy, it seems an unfortunate example to pick something that had 2 catastrophic failures out of 135 launches. Although, I suppose, neither of them were due to software...

There were many other close calls, most having to do with the thermal system on the external tank, which is what damaged Columbia. It was a known issue for almost the entire program.

As you said, nothing having to do with the control system.

Re: Please do not attempt to simplify this code

#19

Post by nerdponx »

startupdiscuss wrote: post #3

The comment:code ratio is higher than anything I write or that I’ve seen. However, it does give me some comfort. When it’s not gamed, do other HNers also feel that a high comment:code ratio probably indicates quality? There are reasons why this may be the case. (More thought, more time and a large team etc) I don’t advocate using this measure to reward anyone because it would be gamed immediately.

Knuth allegedly attributes the stability of TeX to his literate programming style.
Post reply on HN