emm... no, please. like the enthusiasm though
Please do not attempt to simplify this code
591–600 of 647 posts
Re: Please do not attempt to simplify this code
#592Earlier quoted context omitted.
> As a novice programmer, I was absolutely stunned that this was not standard practice. I agree with your point, and I will be benefit from this style if it were the standard, too. But don't you think a good community culture can make people maintain a good git history for this purpose? My daily job is a Linux kernel developer. I found that source codes are only the "What" part, git comments can and should state the…
I've never seen a git commit comment describing the "why" of code. "Added foo.\n\nImplemented az Bar because of blorgz." isn't nearly enough of a rationale, and that's the best description I see people making. Also, the whole point of putting something in a comment is that you have to read it when working through code around that comment. Putting a note in a commit log instead ensures that crucial information importa…
Seen from our offshore with regularity:
> Minor fix
> Showing 6 files with 171 additions and 203 deletions
Re: Please do not attempt to simplify this code
#593This is not compliant with the JPL/NASA Coding Standard: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Calling this "Space Shuttle Style" is an appropriation of credibility and an insult to the engineers of STS.
Re: Please do not attempt to simplify this code
#594Earlier quoted context omitted.
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 business processes were never that complex.”
That’s a falsifiable claim. Human problems / laws are some of the most difficult to code for, IMO. Examples: legal software, economics software, etc. Usually complexity increases as you delve out of the abstract and deal with real-life processes with humans.
Re: Please do not attempt to simplify this code
#595Of course this can be improved and simplified.
Handling 12123123 err checks is a problem of avoiding short circuit failures. That's fine, but you have multiple return values, so there's no reason not to leverage that properly...or even consistently. The whole file is littered with waiting assignment until a comparison, except in some cases or where if and elseif statements use the return values inline but not other places. It's just random.
//checkVolumeSatisfyClaim checks if the volume requested by the claim satisfies the requirements of the claim
func checkVolumeSatisfyClaim(volume *v1.PersistentVolume, claim *v1.PersistentVolumeClaim) error {
// check if PV's DeletionTimeStamp is set, if so, return error.
if utilfeature.DefaultFeatureGate.Enabled(features.StorageObjectInUseProtection) {
if volume.ObjectMeta.DeletionTimestamp != nil {
return fmt.Errorf("the volume is marked for deletion")
}
}
volumeSize := volume.Spec.Capacity[v1.ResourceStorage].Value()
requestedSize := claim.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)].Value()
if volumeSize Re: Please do not attempt to simplify this code
#596Earlier quoted context omitted.
> This is a feature of several (mostly functional) programming languages, e.g. Haskell I didn't see that. In fact this speaks to me as mission critical software like this needs to be as tediously documented as possible to eliminate surprises. Those branches and conditions are collected through a huge pool of trial-and-errors, implying Haskell can provide those valuable use cases out-of-box is misleading, no it can't.…
I think what the parent comment referred to is that in Haskell if/then/else is an expression (like everything else) so you must by definition have to have an else “branch”. Basically it frees you from a subtle type of error.
Those are micro level features. For mission critical module like this, it is unlike those low-level bugs will be left without notice.
But the true complexity is coming from states, and combination of states, and many of those are unknown to the developer until certain incidents kicked in. Good programming practice can't relieve programmers from the cognitive burden of reasoning the outcome of those combinations.
Re: Please do not attempt to simplify this code
#597Re: Please do not attempt to simplify this code
#598Earlier quoted context omitted.
> So yes, just because you use a functional programming language won't help you sell your widgets or make a great product. And you can spend lots of time fucking around with it for its own sake and still not sell widgets or make a great product. It comes down to trust. You're either fucking with your code in a powerful programming language that lets you do everything, or your fucking with the language restrictions to…
I have also developed a strong preference for the latter. I was always on the fence until I got my hands on generative testing (quickcheck, etc). Now I want the powerful language and I can just slam it with generated tests to get the same level of confidence as the guardrail languages (in practice definitely, although I understand this is not true in theory, so unspit your coffee Haskell people). Oh right and this is…
Writing good generative tests is extremely laborious, in general. It's hard to get an informative sample of the input space.
Re: Please do not attempt to simplify this code
#599Ignoring the initial boilerplate (license, imports) and the request to preserve the verbose ("space shuttle") style, the first line is: // Design: // // [... 4 paragraphs of English prose // explaining goals and intent... ] That's exactly the type of comment that should be at the beginning of most files!
Sure, and then the next day the whole thing is just a long boring text which has no correlation to reality because the business rule changed and the developer next to you refactored the code.
This is one reason I like cucumber -- capture features in plain english, and also write tests to verify your plain english features actually work.
It's an odd feeling, having the best of both worlds.
Re: Please do not attempt to simplify this code
#600Love this thread. I see this a lot, where engineers blindly follow best practices and have urges to re-factor code when its not necessary. Big files are not necessarily bad and I love that a lot of the comments are with me on this. Having to open several tabs and remembering where you are in the stack can be hard once there are more than a couple of frames / function calls in. There is a lot of benefit to keeping log…
> As with all engineering, there are always trade-offs to every decision This is the cliche that needs to be put to rest. Yes, often there are tradeoffs. But just as often one thing is better than another thing, and there is no tradeoff. A worldview in which everything has pros and cons and is ultimately subjective is fertile ground for entrenched habits, because it means never having to admit you're plain wrong, tha…
I believe code design is ultimately subjective. Unlike other metrics like performance which can be easily and definitively measured, you can't easily measure 'good' code. The definition of 'good' changes based on the context of the code base and function the code is trying to achieve. In this case, choices like having giant functions and files is definitely subjective.