201–210 of 327 posts
// 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?
if err != nil {
return "N/A"
}
Earlier quoted context omitted.
Comments (should) explain the "why" not the "what". The "why" doesn't go out of date, even if the "what" does.
The why can also go out of date. Maybe not as frequently? I don't have a great intuition for the ratio, but it is certainly more often than never.
Though, obviously, accidents happen, etc. But then that also happens with tests and everything else. I have definitely seen out-of-date tests in code bases, where the test is no longer relevant but still maintained.
Earlier 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…
Heck, it does't even need to be another person. Even me 10 months from now who may have forgotten some context around some code will appreciate boring code.
If they do, changes that disrupt handling some cases ought to be detected by the tests.
Earlier quoted context omitted.
If the 'if' condition matching always results in a thrown exception, a return, or likewise, then you don't really need an 'else' unless you're using a language which supports conditions and resumption (conformant Common Lisp implementations, and not really anything else I know of). The 'else', implicitly, is that the flow of control leaves the scope of the 'if' block at all. (I haven't read far enough into the code t…
"Else" is for when the if condition is false. A resumable exception initiated in the "then" part of an if will not go to "else" when control resumes; it will go to the next statement after the if.
One typically available restart is to ignore the condition and resume execution immediately after, as you describe. Another is to re-evaluate the form in which the condition was signaled. In that case, the conditional may well be itself re-evaluated with a different result, executing a different branch.
Beautiful. ---------------------------- 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…
Earlier quoted context omitted.
Agreed. Explicitness and comments are very useful in understanding the intended functionality and logic, whether or not the code actually implements that intent correctly (an in providing that intent, they can help identify bugs earlier than they would be identified otherwise).
But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.
Earlier quoted context omitted.
It would be interesting to see the NASA approach compared to how SpaceX does things. Considering that they have done manned missions they seem to have very similar requirements.
It'd depend on what software is under consideration. IIRC the UI in Crew Dragon is using more contemporary stuff, Node.js I think. This is fine because they have redundancy, there's minimal crew control anyway, and there are manual overrides behind a panel below the screens. They have 3 relatively modern CPUs setup to run the same code and error check each other, such that if one has an issue, there's still redundanc…