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

191–200 of 647 posts

Re: Please do not attempt to simplify this code

#191

Post by coding123 »

Klathmon wrote: post #21

I love this! It's the "jazz music" of software development. Something which breaks all the "rules" but does so purposefully and explicitly so that it can become better than the "rules" allow. A naive look at this and my head is screaming that this file is way too big, has way too many branches and nested if statements, has a lot of "pointless comments" that just describe what the line or few lines around it is doing,…

It's freaking kubernetes, so obviously it will be a well understood file by a LOT of people. However this is the kind of file that also exists in unknown, non-open source products, and while may have been understood by lots of people (at the respective companies) sometimes a period of 5 years of inactivity and layoffs and hiring goes by... By gosh darn it- this is it. It's the reason we have shitty code but great products.

Re: Please do not attempt to simplify this code

#192

Post by TeMPOraL »

usrusr wrote: post #174
TeMPOraL wrote: post #102

Earlier quoted context omitted.

> Having everything in one file like this without breaking it into "sub modules" for various parts of the module means that you need to almost have a complete understanding of the module before working on it. There's a balance to be struck here; you want to minimize the size of the code a developer has to understand to work on (or with) a given abstraction, but you don't want to split beyond that point, as it only ma…

Java (like many other languages of that generation) suffers from a lack of idiomatic 1:1 visibility. Whenever you split something up in Java it litters a namespace that is much bigger than necessary. Even private is too big when the class is full of tiny methods most of which most will never be meaningful to any of their peers except for that one call site. Sure, you can create inner function objects and with 8+ it's…

Agreed. I don't remember much from my brief exposure to Pascal years ago, but spending a good chunk of my programming years in Common Lisp has spoiled me; the simple ability to nest functions is something I sorely missed when working on Java codebases.

Re: Please do not attempt to simplify this code

#193

Post by Jach »

jackjeff wrote: post #75

This code would probably a lot shorter if every function call was not followed by a ‘if err != nil’ statement. This reminds me of Win32 programming.

You have to handle the errors somehow... though it's amusing that Go settled around what is essentially Java Checked Exceptions everywhere with the handicap of not being able to automatically propagate (or equivalently an Either type, albeit you can make expressive functional pipelines with that) so you always complect the attempt at doing work in the body, the ability to fail in the type signature, and the requirement to notice and handle the error at the immediate call site after the failure has wiped out any local state there may have been in the called function before it returned. (Hey, sometimes it's nice to have a way to force callers into something, but I want it as a design choice.) The notion of being able to fully decomplect and separate error signaling from error handling escapes both languages though, being that the notion is only as new as the '60s with PL/I or the '80s with Zetalisp (or modernly with Common Lisp)...

Re: Please do not attempt to simplify this code

#194

Post by geofft »

germainelong wrote: post #170
geofft wrote: post #147

Earlier quoted context omitted.

I think you can syntactically state that anything where the check is on the second return value (which is, by convention, the error return) is a "simple error check", and their rule for if statements is always for things that come from a first return value. For instance, this would not be a simple error check: server, err := find_current_server() if server != nil { ... } because if find_current_server() believes that…

What if the second returned variable is not err, but the code using it assumes it is? (the code breaks the convention) This will not be accounted for. This means with that in mind a lot more discipline must be used to analyse the code that is being used in that module.

I think that is highly unusual in Go (but someone who actively uses Go would have to correct me).

Besides, this syntactic rule is not implemented by code but by the author and reviewer, who should know what the function returns. (And shouldn't name it "err", then.) They're doing the best they can in a language without syntactic support for what they want, I think.

Re: Please do not attempt to simplify this code

#195

Post by maxander »

Literate programming [0] is frequently re-invented, in various forms, because it is simply the right way to do things- and each iteration of it is almost immediately discarded, because we're all sinful and impatient creatures.

[0] https://en.wikipedia.org/wiki/Literate_programming

Re: Please do not attempt to simplify this code

#196

Post by beefeater »

dajonker wrote: post #16

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

If you need to make sure every condition is handled, write a test for every condition.

Re: Please do not attempt to simplify this code

#198

Post by tigershark »

TeMPOraL wrote: post #160
lozenge wrote: post #151

Earlier quoted context omitted.

Everyone can have comment blindness to some extent, but I've worked with two people who auto-collapsed docstrings and didn't read and hence update comments, which is enough (one person writing code without updating comments/docstrings and one person inadequately reviewing). Sure, the problem only appears in a bit of the code, but it means people stop trusting all the comments.

> auto-collapsed docstrings Woah, that sounds like a pretty dumb feature. Auto-collapsing whole functions is useful, but auto-collapsing docstrings sounds like a recipe for disaster. People write docstrings and inline comments for a reason.

No. Autocollapsing doc strings is not dumb at all, it’s an amazing feature. Most of the time in my experience the doc strings are completely useless when you are writing code, they may be useful only for the caller because they give you info in the autocompletion (and most of the time is just “get this value” “set this value”) and they can be used to automatically generate api docs. If they are extensively used in a private project that no one will call from a different one I will auto collapse them. They take so much space for nothing and they slow me down terribly. And the projects in which I have seen this behaviour had horrible methods naming, clueless architecture and completely arbitrary method subdivision. The doc strings where just the wrong solution for the wrong problem.

Re: Please do not attempt to simplify this code

#199

Post by sitkack »

brandall10 wrote: post #47
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.

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.
Post reply on HN