Kubernetes, eh? (strikes through its name on my list)
Please do not attempt to simplify this code
121–130 of 647 posts
Re: Please do not attempt to simplify this code
#122The comment claim that every branch is accounted for and yet few functions below you can see this is certainly not the case. They should either have fixed it first and then make such comment or shouldn't make such comment at all. Otherwise this looks a bit cringey.
It says "(exception: simple error checks for a client API call)" and that seems accurate to me. In particular Go (like C) has no built-in exception "throwing" / unwinding support, so for any function call where you want to pass an error onto the caller, you need to do something like result, err := try_to_get_a_result() if err != nil { return nil, err } See also https://blog.golang.org/error-handling-and-go . As far a…
Is someone not familiar with the code competent enough to decide what is a "simple error check" and not a bug? This is very weak as they suggest that even the branches that would result in no-op are accounted for. So if someone introduce a code with a branch that is unaccounted for that automatically means the code is either faulty or is a "simple error check". With something supposedly trying to be a space shuttle worthy code the lack of definition of "simple error check" is very worrying. Would I want this code to fly me to the moon? I'd be wary.
Re: Please do not attempt to simplify this code
#123The 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.
It's really only useful in areas of codebases that either a) are very complex, b) touched by many people or c) both. When that happens, everyone prefers that there is a lot of documentation, especially about the why. With older codebases the question is always whether this is an actual bug from the developer or is there a reason why it's doing this super-weird thing and if so is it still applicable. What's happened o…
You've missed d) the codebase lives longer than a few months and someone else than the original author has to make changes. Comments describing the intent and caveats are extremely useful in ensuring the future developer gets adequate understanding quickly, and reduces the chance they'll introduce bugs.
Tests can help understand the interface, but they don't help to understand the rationale behind it, the underlying abstraction, or implementation caveats.
Re: Please do not attempt to simplify this code
#124Kubernetes, eh? (strikes through its name on my list)
Why? Does this file/comment cause you to lose confidence in the project in some way?
I'm genuinely curious to understand the reason for your comment.
Re: Please do not attempt to simplify this code
#125Earlier quoted context omitted.
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.
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
*
* @param user The user to bill
*/
public void billUser(User user) {
//
}
Re: Please do not attempt to simplify this code
#126Earlier quoted context omitted.
> probably a hell of a lot easier to maintain and manage than splitting the logic up among tens or hundreds of files I'm only halfway through John Ousterhout's book Philosophy of Software Design but I think it agrees with you on this -- that smallness-of-file or smallness-of-function is not a target to shoot for because it prevents the things you build from being deep. That you should strive to build modules which ha…
Now i'm squarely in frontend web-app development right now which definitely changes things (mainly the complexity is centered around enabling fast changes/additions to the codebase, and not the actual business logic for the most part), but while "deep functionality and small interfaces" sounds good on paper, most of the time giant files with a few functions exported aren't a good way to manage that. Sure, it solves t…
Breaking things down into smaller pieces is good when it’s good... but there are drawbacks that I feel are often ignored.
For example, as you say, a small piece of stand alone code implies that someone can do meaningful work on it without understanding the entire context around it. It also implies that it is suitable for reuse. But if it’s both reused liberally and encourages you to keep working on it, it will almost certainly mean that your changes will have unanticipated consequences. So you still can’t get away with being unaware of the context.
When you break things apart you also fossilize that way of approaching the problem, which often makes it more difficult to see orthogonal approaches and refactor towards them later. Instead you keep working within the structure that’s already there, which often leads to concerns being spread out across different modules. Too often people decide on the structure before they even understand the problem.
I think it has similar problems as religiously following the DRY principle. There are so many situations where your code will be much, much worse if you insist on always sticking to DRY.
Re: Please do not attempt to simplify this code
#127Re: Please do not attempt to simplify this code
#128Earlier quoted context omitted.
I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company. Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them…
All the better hamburgers cost more
Not true in the UK, McDo really ain't that cheap anymore (or perhaps I'm poorer than I think).
The better burgers made by large commercial chains are more expensive though.
Re: Please do not attempt to simplify this code
#129Earlier quoted context omitted.
I know a business coach who regularly asks his audience "Who here makes better burgers than McDonalds?". When half the audience raises their hand, he asks them why they don't outsell this giant company. Functional programming advocats, especially for the "pure" ones like Haskell, always strike me as odd. It seems that all the beauty of those languages make people obsess over that beauty and purity while keeping them…
Selling a lot of burgers encompasses much more than making good burgers. By the same token, good products entails much more than making a programming language choice. Functional programming, at its heart, is about using self-imposed constraints to avoid certain classes of programming mistakes. If your application domain doesn't have big consequences for these classes of programming mistakes, then it can seem like fun…
Now that's an excellent point, I agree. However, at its heart, Kubernetes does not even have that many distributed features. It's a rather classic master-slave architecture that shells out a lot of distributed primitives to etcd (which could be a much better candidate for the points you mentioned), but on the other hand, it's a mainly a system orchestration system that juggles an operating system, syscalls, SECCOMP, firewalls and related stuff — exactly the area where Golang shines and Haskell would have a rather hard time.
In this way, I rather like the tradeoff that the OP post shows: It's at least _possible_ to write Go code that's almost as defensive, safe and exhaustive as a safer language could provide, it's just a lot of manual work and discipline. For the small subset of code that needs these guarantees, it's possibly overall more consistent and efficient to take this route than splitting code into different languages with different strengths.
Re: Please do not attempt to simplify this code
#130Earlier 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 disagree. I like the taste of McD!burger and I like the taste of foodtruck!burger. They are entirely different tastes; sometimes I want to experience the former, sometimes the latter.
No-surprise factor isn't that big of an issue if you're buying; restaurants tend to have consistent food quality & taste too.