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

391–400 of 647 posts

Re: Please do not attempt to simplify this code

#391

Post by majikandy »

kraftman wrote: post #45
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.

'A comment is a failure to express yourself in code. If you fail, then write a comment; but try not to fail.' - https://twitter.com/unclebobmartin/status/870311898545258497... And a bit more on the same from clean code: http://www.kyleblaney.com/software-blog/2012/6/29/comments-a...

Finally, can’t believe I had to read this far down in the comments to find a reference to clean code.

Re: Please do not attempt to simplify this code

#392

Post by tonyedgecombe »

coldtea wrote: post #119
TeMPOraL wrote: post #111

Earlier quoted context omitted.

> It's certainly not that McDonald's makes better (or "simpler") hamburgers At the risk of derailing the thread, that would be the lesson I wish people would take away from that example. Criticizing fast food like that is dumb signalling IMO; McDonald's!hamburger != homemade!hamburger. It's an entirely different product sharing the same name and some of the ingredients. It tastes different, and has a different form f…

> People like this, even if many don't want to admit it to others (or themselves) People only like the cheapness and the convenience (and perhaps the no-surprise factor). Everything else being the same (price and time to prepare), nobody would eat McDonalds vs a quality burger (except the kind of people who eat Hot Pockets for the taste, but that's a much smaller demographic than McDonalds buyers).

I remember watching a TV program where they took some typical fast food (McDonalds, KFC, etc) and presented it on a plate in a way you would expect in a more expensive restaurant. Everybody who tasted it rated it higher than food from the the fast food chain.

It seems many or even most people can't tell the difference and the ambience and service is as important as the food.

Re: Please do not attempt to simplify this code

#393

Post by c3534l »

lmm wrote: post #7
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 likely to indicate low quality. Comments are for where the code wasn't clear enough.

This sounds like a self-fulfilling prophesy. If only think comments are for telling you what a line of code does literally, then you're only going to see comments where the code is obscure. If you use it as a form of high-level communication to help the user understand the broader context and reasoning behind code (like at the top of the linked page), then it will be useful because the person writing the comments understands why documenting your code is a good thing.

Re: Please do not attempt to simplify this code

#395

Post by m_mueller »

TeMPOraL wrote: post #336
BurningFrog wrote: post #325

Earlier quoted context omitted.

Sure. In sane code the name of the function should describe what they do well enough that you rarely have to click in to learn how they do it. Or something like that...

That applies recursively to the function you're just reading :). I.e. I wouldn't be inside a particular function of a particular module if I didn't have to know something about its implementation. There's a good chance I need to understand all of it at the level of abstraction of the module (often because I'm supposed to change something about it). Making that less painful leads to better and less bug-inducing experi…

Totally agree on nested functions. I currently have to deal with Java, and those are the biggest thing I miss from Python.

Re: Please do not attempt to simplify this code

#396

Post by bitexploder »

arduanika wrote: post #331
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…

In this case, the questionable choice of a "something" to handle the complexity is jarringly at odds with the high economic importance that the comments convey. > tests pv_controller.go has 1715 lines. To be generous, we might say half of it is comments. pv_controller_test.go has 359. Hopefully this code is exercised elsewhere in integration tests? > a huge QA department That's what you're signing up for when you cho…

I don’t think this changes the inherent complexity of the code right? The basic logic of what is being done is still the same. De-indenting code but still having the same complexity, some of which is now abstracted by the language is still complexity. Maybe it somewhat helps the humans reading the code? But don’t you still have to reason about the basic state changes of the system the same way?

Re: Please do not attempt to simplify this code

#397

Post by fouc »

sitkack wrote: post #199
brandall10 wrote: post #47

Earlier quoted context omitted.

The comment:code ratio is similar to some legacy enterprise C/C++ systems I've worked on. I've been on Rails/React teams where comments were seen seen as a possible smell. Not talking about useless literal comments, just that their need was seen as pointing to possible bad design and that a well factored codebase was self-documenting -- ie. if you had to comment something, perhaps methods/vars were poorly named, SOLI…

I have worked on teams with this same attitude, and in my case it was just a systemic way for the group to rule-away having to write comments. The codebase suffered for it.

Probably depends a lot on the programming language.

Re: Please do not attempt to simplify this code

#398

Post by james_s_tayler »

hexane360 wrote: post #338
james_s_tayler wrote: post #262

Earlier quoted context omitted.

Twice the time it takes you to write half a sentence.

Hard disagree. You still need to think of the sentence to write the first half.

Beg to differ. I consider the time taken to think and write as the aggregate time to write the sentence.

Re: Please do not attempt to simplify this code

#399

Post by bitexploder »

jonahx wrote: post #347
TeMPOraL wrote: post #333

Earlier quoted context omitted.

> I assume everyone who splits code into smaller pieces use modern IDEs that makes it trivial to navigate to functions by clicking them etc. That's... not the point. Jumping around is. Imagine reading this comment thread on a bizarro-HN, where you only get to see a short camelCased summary like: debunk(this.previousComment), and have to click to open each comment in a new tab. This is how jumping around small functio…

> That's... not the point. Jumping around is. There is a tradeoff: Small functions make high-level logic clearly visible and easy to find, at the price of forcing you to jump around when you want to dive into implementation details. Putting everything into one big function lets you follow all the implementation details without jumping, at the price of making you read everything to actually understand what the code is…

Wasn’t that the purpose of the long comments: To sketch out the high level logic, while keeping all the code in one place. Jumping around, you now have to do that to be sure of the details and the complexity can be hidden in layers of functions. Complexity that often matters.

Re: Please do not attempt to simplify this code

#400

Post by spullara »

My take away from reading this code is that it is a huge mess that may be impossible to clean up. At some point they failed to introduce abstractions that would remove the need for all this complexity. They are probably right that now that it works that it will be hard to refactor it without leaving out some critical case. However, I pity anyone that works on this code base.
Post reply on HN