When we have this on code is because we failed in something else.
Please do not attempt to simplify this code
231–240 of 327 posts
Re: Please do not attempt to simplify this code
#232Beautiful. ---------------------------- This controller is intentionally written in a very verbose style. You will notice: 1. Every 'if' statement has a matching 'else' (exception: simple error checks for a client API call) 2. Things that may seem obvious are commented explicitly We call this style 'space shuttle style'. Space shuttle style is meant to ensure that every branch and condition is considered and accounte…
The newer `satisfies never` is great for this purpose. It’s also convenient with if else chains if that’s more one’s style.
Re: Please do not attempt to simplify this code
#233// CSINameTranslator can get the CSI Driver name based on the in-tree plugin name type CSINameTranslator interface { GetCSINameFromInTreeName(pluginName string) (string, error) } Do people actually find comments like the above useful?
yep, they are useful.
I consider comments to live at "conceptual" level while code lives at "physical" level.
With this way,when you are debugging, your mind can read code at conceptual level and easily disregard irrelevant blocks of code. without comments, i will need to mentally drop down at physical level and implement a compiler in my brain for the same results
Re: Please do not attempt to simplify this code
#234Earlier quoted context omitted.
The Go ideology is basically to just write down all the code, in a more or less straightforward translation of what you would have written in C, and not to try to abstract anything.
Which is an underrated ideology. I once had to go through some code that was objectively terrible. The guy who wrote was is a mechanical engineer, close to retirement at the time, and self-learned in programming. He had absolutely none of the background you can expect a professional programmer to have, and in particular abstraction seemed like a foreign concept to him. Have 50 buttons, each doing essentially the same…
If you saw the 50 copy-pasted blocks of code I'll bet you mentally abstracted it and assumed they were all doing the same thing. The problem comes when one of them isn't quite doing the same thing. That isn't possible with a real abstraction.
Perhaps as a mechanical engineer the guy understood the more important things, though, like separation of concerns and a layered model, ie. architecture. Truly bad code mixes up all concerns into one ball of mud. Feel like forking a new process right from the GUI layer (the only layer) based on some business logic for that one button press? No problem!
Being able to look at a single piece of code in isolation and understand what it's doing isn't the challenge. Anyone can do that for any code. The challenge is knowing how it runs in context of the larger program. What are the downstream implications of the way it's done? How many times is this run and why? Who is this code responsible to and why would it change (e.g. is it business logic, or just a UI thing)? This is the kind of thing an architecture gives you. You don't need to go all in with abstracting everything, but you do need some architecture.
Re: Please do not attempt to simplify this code
#235Earlier quoted context omitted.
Or maybe between one version and the next they only found one bug (there may have been bugs in the first version which weren't fixed until the third or later) - this seems more plausible to me since it's... rather difficult to count bugs until after you know about them. Of course now the greatness of the feat depends on how much testing there was between versions, but given that it was the shuttle there was probably…
Not just testing - line-by-line code review of the entire system by a panel of experts. Outside of aerospace/defence/nuclear this style of review is not very common.
I don't know about now, but software verification would also be used in consumer electronics.
Fixing a bug in 10,000 washing machine control boards is very expensive when it entails sending a technician to every house to replace the circuit board.
Re: Please do not attempt to simplify this code
#236But do they have tests that achieve 100% condition/decision branch coverage? If they do, changes that disrupt handling some cases ought to be detected by the tests.
I assume no and ultimately that is the point of code like this. As you say, if you can somehow correctly identify every possible branch in your tests then you could write the actual code any way you like. But then the tests would have to look like this, otherwise you'd have abstraction in your tests and you couldn't be sure if it covers every branch. Who tests the tests?
Re: Please do not attempt to simplify this code
#237when i see too much verbosity i sometimes think someone is trying to hide something behind it...
Re: Please do not attempt to simplify this code
#238Earlier quoted context omitted.
I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…
> I strongly prefer the explicitness I have a rule for my teams: "Don't write clever code". I try to constantly reinforce that we don't write code for ourselves, we write it for the next person. We should be doing everything in our power to decrease their cognitive load. I try to envision the person that comes after me (who may be me in months or years!) and imagine that they are having a Bad Day and they have to mak…
That is a good rule. If you want to write clever code, do some code golf. For everything else I heavily prefer explicitness. Smart software architecture hides the verbosity if you do not have business with a specific and most likely specialized piece of code.
Even with ugly code, you should think about refactoring if this particular piece did run successfully for several years and there are no security related issues.
There are several languages the violate this principle. Brainfuck is probably one of the most prominent. It is of course not to be taken seriously. Overall alleged "elegance" of some code parts is rather annoying if you really need to understand and adapt it.
Re: Please do not attempt to simplify this code
#239I love this style of coding and it's something I've been doing increasingly more over the last few years. Code verbosity is so underrated in so many dev teams. I have never had a co-worker complain that my code was too well documented and too easy to understand, quite the contrary actually.
When someone advocates for more concise code by saying that it's "easier and quicker to read" I always counter that if you use a lot of language feature magic to make code more concise then the mental work to read the code remains the same, the only difference is that you ask your co-workers to leave the editor and google lots of things in order to understand your brief code versus keeping them in their editor and just being able to read the simple verbose code without interruption in one place.
Re: Please do not attempt to simplify this code
#240But do they have tests that achieve 100% condition/decision branch coverage? If they do, changes that disrupt handling some cases ought to be detected by the tests.
I assume no and ultimately that is the point of code like this. As you say, if you can somehow correctly identify every possible branch in your tests then you could write the actual code any way you like. But then the tests would have to look like this, otherwise you'd have abstraction in your tests and you couldn't be sure if it covers every branch. Who tests the tests?
You test the test by mutating the code. Once you have 100% condition/decision branch coverage you can automatically sweep the code with changes and the tests will fail.
I have a little harness I use for this steps through each non-comment line of code changes signs, comparison directions, offsets values, swaps variables, adds negations, replaces computations with constants, etc. basically changes that are more or less guaranteed to compile.
Then it runs the compiler to produce a stripped optimized output, if the compiler is successful, it checks that the resulting md5 is different from all the prior results, runs the tests. If the tests pass, it saves the passing code (which, to be clear is a meta-test failure), and then later I sweep through and either determine that it managed to produce functionally equivalent code or I improve the tests (and fix the resulting bugs they expose).
The identical compiled binary test eliminates a lot of false positives.
But that kind of approach doesn't work unless you get to ~100% condition/decision branch coverage since obviously any condition that isn't tested will be free to mutate.
Hm. Maybe if I updated it I'll have some attempt at sampling LLM rewrites of functions. :P