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

441–450 of 647 posts

Re: Please do not attempt to simplify this code

#441

Post by AstralStorm »

TeMPOraL wrote: post #359
fogetti wrote: post #357

Earlier quoted context omitted.

Or maybe the original developer who wrote the code which was so poorly written that it needed 4 paragraphs of explanation did a shitty job . Period. They need to be told to go back and fix it. You see! You argument works both ways, yay!

Of course it does. If the comments are completely redundant with the code, they're bad. But you can't express as code why the some code is the way it is, and why it does what it does. After you tried to express in code every important information that's expressible as code, whatever important information remains must go into comments.

You could. It is called an automated theorem prover, with the cheap limited version called constraint based programming. Sadly very unavailable for most programming languages.

Sometimes writing the proof of why it should be like this is tricky, especially when complexity or performance is involved. (But then the tests are hard too.)

Linters are essentially constraint systems for code, but not for the program.

Re: Please do not attempt to simplify this code

#444

Post by vectorEQ »

zorga wrote: post #274
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.

> do other HNers also feel that a high comment:code ratio probably indicates quality? Nope, imho code with lots of comments is generally crappy code. It's littered with comments to explain the sloppy code they couldn't make clear because they're bad programmers. Good programmers use few comments, write simple clear code that doesn't require explaining, and leave comments about why something was done rather than simpl…

i would say like you say it depends on the quality of the comments documenting the code. if they are correct then it shows a thorough understanding of what is written in code, apart from that a complete stranger to the code can easily find what they need. however, like you said, you will need to maintain comments more than code, which is a pain and will lead to inconsistencies in the comments, leading to crappy file with meaningless junk scattered in it, which in turn means you can never trust comments, and it's therefore kind of useless to have. :d but since that's a circular argument, and those tend to be just cynical in nature, i do prefer properly commented code above uncommented code. i'd do it less verbosely myself so i don't need to maintain so much of it though, trying to keep it more consistent over time.

Re: Please do not attempt to simplify this code

#445

Post by AstralStorm »

Readability is not a valid requirement as it does not specify a valid end condition.

Likewise simplicity is not a valid requirement. Code coverage by tests, proofs and comments is.

A valid requirement could be considered complexity, number of names and entities and a lot of other linter constraints.

Heck, aggressive deduplication is not even always good.

Self similarity is not necessarily good either (the reuse of patterns) as you could have problems trying to spot the differences and special cases as they may no longer stand out.

Re: Please do not attempt to simplify this code

#446

Post by lmm »

rakoo wrote: post #435
arduanika wrote: post #331

Earlier quoted context omitted.

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…

So basically complexity would go in the language

A language that spends its complexity budget well can save complexity from a lot of programs. E.g. if you look at https://philipnilsson.github.io/Badness10k/escaping-hell-wit... , language A could offer all 5 of those ad-hoc solutions (making it a very complex language) and language B could just offer monads (making it a relatively simple language), but both languages would be just as effective in alleviating the complexity of programs written in that language.

Re: Please do not attempt to simplify this code

#447

Post by AstralStorm »

msjyoo wrote: post #385
hoorayimhelping wrote: post #370

Earlier quoted context omitted.

> 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.

I'd move the unnecessary big banner somewhere. A website is not a book and does not have cover pages.

Re: Please do not attempt to simplify this code

#448

Post by The6P4C »

bdibs wrote: post #125
mannykannot wrote: post #114

Earlier quoted context omitted.

Well, let's consider an example from this very code: // The binding is two-step process. PV.Spec.ClaimRef is modified first and // PVC.Spec.VolumeName second. At any point of this transaction, the PV or PVC // can be modified by user or other controller or completely deleted. Also, // two (or more) controllers may try to bind different volumes to different // claims at the same time. The controller must recover from…

My comment was directed to the OP's question of comment:code ratio in general, not in this exact circumstance. Additionally, in no way am I advocating for no comments, that's obviously not possible (like your example). Comments are useful, even necessary, for code that might have an otherwise confusing logic to them. I've seen plenty of code with documentation for a method with nothing more than: /** * Bills the user…

Though there should definitely be documentation here. What happens if `user` is null? What if the user doesn't have enough balance for the transaction to complete? What if the transaction fails?

I see this as someone trying to fool a linter that demands they have documentation. I think it's better to say "comment everything" because it puts documentation as a first-class consideration rather than an afterthought.

Re: Please do not attempt to simplify this code

#449

Post by lmm »

kierenj wrote: post #404
spullara wrote: post #400

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.

Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? In this case right here, what's your counter-example, or what would you use instead of their specific approach?

> Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)?

No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're human problems; human business processes were never that complex. So if a program looks really complicated, the overwhelmingly likely cause is failing to use appropriate abstractions.

> In this case right here, what's your counter-example, or what would you use instead of their specific approach?

As others have said, a result type would greatly simplify this code without sacrificing any safety. No doubt after such a simplification made the code shorter and easier to comprehend, further simplifications would become apparent.

Re: Please do not attempt to simplify this code

#450

Post by XenophileJKO »

lliamander wrote: post #256
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…

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 think it might come with experience. I definately gravitate to very small classses/functions, personally prefering classes to fit within a single screen.

Obviously this isn't always achievable.

It comes down to: "What do you want to focus on?" Each drill down should be to a lower level of abstraction. It is seperating the what from the how.

It results in functions/classes that either detail a flow (set of decisions) or that implement actions. For example I generally don't need to know how to read a file from disk where I am trying to decide if I should read a file.

When looking at code you drill down in a very vertical fashion when you want to know "How does it do operation X?" Meaning the operation largely can be understood in isolation. There shouldn't be a lot of context that is required for it. A side-effect is that all the unit tests are very self contained.

This utlimately steers you towards a much more functional and compositional programming style. Certainly it is moving complexity around, but the end result is heavy compartmentalization and limiting the context required to understand any section of code.

Post reply on HN