141–150 of 647 posts
This looks like pretty normal code. What is all the “space shuttle” stuff about? The only unusual things I see are a) 8-space indentation, b) lots of “if err { return nil }”, and c) lots of comments. Aren’t a) and b) standard for Go? How else is it possible to write Go code? With less verbose error handling and 2- or 4- space indentation it wouldn’t look especially “branchy”.
Earlier quoted context omitted.
A good alternative is language-level support for returning early from a function with an error. Off the top of my head, both Rust and Haskell have good support for this. (I'm sure there are others, these are just the ones I know.) Rust has a macro try!(x) that takes a Result - a two-variant type, either a successful result of type T or an error of type E - and translates it to, if x is the first variant, evaluate the…
You missed the E in Result , by the way.
Or pretend I meant io::Result :)
"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…
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…
Much of theoretical physics is beautiful. Only when one takes it off the blackboard and into the real world does it turn ugly.
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).
Earlier quoted context omitted.
Short functions help here. If every function is just a few lines long, the comments are easier to keep synchronized, and if a function drops out of service, it should eventually be garbage collected with its now-irrelevant comments.
But what if comments pertain to unexpected states the system as a whole can be in? Kind of the whole problem is when there are weird corner cases going on that straddle function boundaries. I'm not saying that's a good thing; mind you - but nor is it always trivially avoidable, especially if code needs to be concurrency and/or exception safe -- or in general whenever the statements your function consists of have surp…
If the problem has "hub and spokes" topology, i.e. it's relevant to multiple places in code that all reference a single location, put a comment describing the issue in that single location, and everywhere else put a comment with a reference. //Warning. See comment in [that location].
If there's no single best place for the detailed comment, put it in some design notes file, and put a comment with a reference to that file in all the affected places.
DRY can, and should be, applied to comments as well.
Earlier quoted context omitted.
By naming as much as possible. I'd need to know the rationale in the ticket to be able to try and codify it, but here's how I'd try and do the rest: https://codepen.io/anon/pen/Jwyzdv
I'm not sure that reducing the comments-to-code ratio by increasing the complexity of the code really helps anything. You've made the code more generic for what you currently think future changes are going to look like, which may or may not be accurate. And in the process you've split dateIsOnLeapDay and convertLeapDayToPreviousDay into separate functions, so if someone is tracking down a bug in line 10, they need to…
More lines doesn't mean more complex, it's the same logic just the logic is named now and more reusable. It's possibly not the best example, as the logic is minimal, but when the logic becomes more complex, wrapping it and naming it becomes very powerful. We're creatures of abstraction.
> You've made the code more generic for what you currently think future changes are going to look like, which may or may not be accurate.
I'd argue that I've reduced the number of reasons the code has to change, which should be a goal while programming. If we change how we calculate a leap day, we don't touch how we modify a leap day, which means we're less likely to cause adverse side effects.
> And in the process you've split dateIsOnLeapDay and convertLeapDayToPreviousDay into separate functions, so if someone is tracking down a bug in line 10, they need to jump to lines 20 and 21 to figure out that the associated code is in line 15
They should be separate functions, they are separate things.
> In a large program these would get even further separated over time
Is it really a problem if they are separated? What links them? There could be plenty of reasons for wanting to call one without the other.
Earlier quoted context omitted.
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 w…
For instance, this would not be a simple error check:
server, err := find_current_server()
if server != nil {
...
}
This is almost the worst of both worlds: the trouble of wading through a pile of words, together with the lack of clarity.
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…
With regard to the sample, then if that is your experience, I cannot deny it, but, irritating as it may be, it seems fairly harmless. It appears to date from a time when it was thought that extremely prescriptive coding style standards was the way to fix programming - an even less realistic belief than the idea that code can be entirely self-documenting.