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

381–390 of 647 posts

Re: Please do not attempt to simplify this code

#381

Post by majikandy »

beokop wrote: post #28
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.

Nothing to do with ratio but I’ve found that the quality of the comments often reflect the quality of the code.

No comments are good comments.

Re: Please do not attempt to simplify this code

#382

Post by lliamander »

BurningFrog wrote: post #305
lliamander wrote: post #256

Earlier quoted context omitted.

Martin Fowler of the Agile world, and Garret Smith of the Erlang community, are both excellent programmers whom I respect, and they both take the approach of breaking code into lots of extremely small functions. Having tried that style, I notice that I don't particularly favor it, and for the very reason you site: the code is no longer all in one place. I've switched to moderately sized methods/functions with comment…

I assume everyone who splits code into smaller pieces use modern IDEs that makes it trivial to navigate to functions by clicking them etc. I say this because I'm always astonished by the number of "modern" programmers who refuse to use IDEs.

For Java programming, I definitely use IDE. Even for Erlang programming I use Emacs with EDTS to get a more or less IDE experience.

I'm saying that, even with that convenience, I don't wrapping a line or two in it's own function is more readable than just adding a comment above those two lines within the context of a (somewhat) larger function.

Re: Please do not attempt to simplify this code

#383

Post by majikandy »

vvanders wrote: post #56
josteink wrote: post #35

Earlier quoted context omitted.

> 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 th…

I've seen horrible inheritance/convoluted refactors done in pursuit of DRY. I'm a bigger fan of WET(Write Everything Twice). Usually the first iteration of a component you don't understand enough of the domain space to get the abstractions right. So use that first attempt to explore the issues/problems/corner cases. Once well understood, rewrite it into something concise and well abstracted. I've also find that if yo…

Commonly referred to as rule of 3. Write it out in full twice, on the 3rd time it must be a real abstraction, therefore refactor.

Re: Please do not attempt to simplify this code

#384

Post by jcoffland »

The code referenced here is extreme. It does not consider diminishing returns or acknowledge tradeoffs in readability. I would advise a more balanced approach.

A more compact style allows more code to be viewed at once making it easier to understand. Of course, taken to the other extreme, overly compact code becomes hard to read.

It's called, "the art of computer programming", because blindly applying programming principals rarely yields good results.

Re: Please do not attempt to simplify this code

#385

Post by msjyoo »

hoorayimhelping wrote: post #370
3pt14159 wrote: post #277

Earlier quoted context omitted.

I've had this latent thought for a while that I'm finally putting to words: The complexity goes somewhere. It's either into lots tests, or it's into something like shuttle style with lots of comments, or it's into a huge QA department, or it's into the type system / DB schema. It could even be going into the org structure! But something, somewhere is handling the complexity and it is doing so as a partial function to…

> Tesler's Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced. https://lawsofux.com/teslers-law.html

Wow, that site is beautiful beyond words.

Re: Please do not attempt to simplify this code

#386

Post by yoz-y »

Honestly, to me this looks like normal good code. It reads from top to bottom, exits early, does not have conditions so long that they require lines to be wrapped, it has function that are long or wide but not both... Does not seem to superfluously refactor code into functions called only once.

Maybe there are too many comments, but for code that is critical and might be harder to understand at a glance that is better.

Re: Please do not attempt to simplify this code

#387

Post by jonahx »

Xyik wrote: post #377

Love this thread. I see this a lot, where engineers blindly follow best practices and have urges to re-factor code when its not necessary. Big files are not necessarily bad and I love that a lot of the comments are with me on this. Having to open several tabs and remembering where you are in the stack can be hard once there are more than a couple of frames / function calls in. There is a lot of benefit to keeping log…

> As with all engineering, there are always trade-offs to every decision

This is the cliche that needs to be put to rest.

Yes, often there are tradeoffs. But just as often one thing is better than another thing, and there is no tradeoff.

A worldview in which everything has pros and cons and is ultimately subjective is fertile ground for entrenched habits, because it means never having to admit you're plain wrong, that there is a better way, or that other approaches are simply that much better than yours.

Re: Please do not attempt to simplify this code

#388

Post by majikandy »

lazyjones wrote: post #136
josteink wrote: post #35

Earlier quoted context omitted.

> 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 th…

> 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. Can you name a few examples where you encountered this? In my career (30 years programming) I've never seen it. I believe it's a common, poor excuse for not writing enough comments. The benefits of comments are well-understood. For me personally they often helped compens…

Are you serious? Almost every codebase that has comments has code that doesn’t exactly match the comments. Main obvious reason being that the comments aren’t executed whereas the code is. Sure meticulous attention to detail could keep the two in the sync. But you are suggesting that they have always been in sync for any code you’ve looked at?

As someone who is clearly a fan of comments, are you saying you’ve never modified a comment to make it more accurate to what the code is doing?

Re: Please do not attempt to simplify this code

#389

Post by wreath »

thaumaturgy wrote: post #209
TeMPOraL wrote: post #94

Earlier quoted context omitted.

I just finished his book yesterday; he has a lot to say about size and comments. For size, your summary is spot-on. I'd only add that he notes overeager splitting of methods and classes makes code involved in a particular abstraction to be no longer in one place, leading developers to constantly jump around files, which makes it more difficult to understand the code and increases the chances of making bugs. As for co…

> I'd only add that he notes overeager splitting of methods and classes makes code involved in a particular abstraction to be no longer in one place, leading developers to constantly jump around files, which makes it more difficult to understand the code and increases the chances of making bugs. Another way of describing this, that I ran across recently, is that this increases the cognitive load for developers workin…

> Another way of describing this, that I ran across recently, is that this increases the cognitive load for developers working on the code, and cognitive load is one metric by which code can be measured as "good" or "bad". Things like excessive scrolling and switching between files increases cognitive load.

Actually that’s one the reasons why he advocates not splitting code (arbitrarily) in the book.

Re: Please do not attempt to simplify this code

#390

Post by majikandy »

spyspy wrote: post #15
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.

So true.
Post reply on HN