Pattern matching would be nice in this scenario. Would help with isolating responsibility by breaking out the if statements into functions responsible only for the case they know to handle. The additional opportunities to name with more granularity could minimize the comments needed.
Please do not attempt to simplify this code
31–40 of 647 posts
Re: Please do not attempt to simplify this code
#32What's up with that tab size? Is that normal for go code?
Re: Please do not attempt to simplify this code
#33The 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.
No, I do not find it indicates quality.
To me, comments are noise, and code is signal; the code is what actually executes.
It's one thing to have a summary of intent at the start of a listing, that should not count towards the code:comments ratio.
Once the code begins however, there should be a minimum of comments necessary - especially in a high-level language not constrained to assembly-level instructions.
In assembly listings it was common to have two columns, the code on the left and comments which often resembled high-level pseudo code on the right. Here's some representative apollo guidance computer source:
MAKEPRIO CAF ZERO
TS COPINDEX
TC LINUSCHR
TCF HIPRIO # LINUS RETURN
CA FLAGWRD4
MASK OCT20100 # IS PRIO IN ENDIDLE OR BUSY
CCS A
TCF PRIOBORT # YES, ABORT
Re: Please do not attempt to simplify this code
#34"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…
Why do you say Haskell is an example of this? You can return undefined for anything, and have incomplete pattern matching, where if you don't mention a particular case, there is a runtime crash.
An example would be head, which takes the first element of a list and throws an error on an empty list.
I really love Haskell but it seems as if they are going for something different here than what Haskell provides.
Re: Please do not attempt to simplify this code
#35The 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.
> do other HNers also feel that a high comment:code ratio probably indicates quality?
I consider it a big risk of errors.
When some code is changed, will all related comments be rewritten too? I doubt it.
And then you end up with a codebase which indicate A but comments which clearly spell out B, and you as a maintainer have no idea what to believe.
DRY. Don’t repeat yourself. The comments should not double up for the code. That’s just future maintenance nightmare.
Re: Please do not attempt to simplify this code
#36The 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 actually would say it’s almost the opposite, if you’re writing clean, expressive code it shouldn’t need explaining. And if your code is clean, you shouldn’t have a bunch of redundant comments explaining the obvious.
While your fundamental point is very valid, there are plenty of times where a comment to flag up a fine point of your clean and precise code will save future-you hours of head-scratching.
I absolutely do not comment enough, but knowing this, I try to stick to the principle that if I have had to stop and think through an expression before I write it, then I am likely to eventually thank myself for leaving a short explanatory note.
And moreover, it may not be me scratching my head over that nest of ternaries in a year's time - it may be some other poor soul. And while that poor soul won't thank me for leaving a comment, he or she will certainly curse my name - quite possibly vocally and publicly - for not leaving one.
Re: Please do not attempt to simplify this code
#37This style is common in large enterprise C++ code bases and is definitely useful when LOC exceeds a couple of 100k and the business logic complexity is high, and the project is mission critical and expected to be around for many years.
Re: Please do not attempt to simplify this code
#38"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…
Why do you say Haskell is an example of this? You can return undefined for anything, and have incomplete pattern matching, where if you don't mention a particular case, there is a runtime crash. An example would be head, which takes the first element of a list and throws an error on an empty list. I really love Haskell but it seems as if they are going for something different here than what Haskell provides.
[deleted]
Re: Please do not attempt to simplify this code
#39Is there any evidence that writing code in the demonstrated way produces higher quality? No? None at all!? Then why should I believe it? I might as well embrace healing and homeopathy too...
I'd rather write my code like its written in the Linux kernel. There is no evidence that that style is better either, but at least Linus has provided loads and loads of arguments in favor of it on a mailing list.
Re: Please do not attempt to simplify this code
#40I'd like to see Uncle Bob do a point-by-point critique of this... "piece of work"