The fantastic documentary “We Are As Gods” about Stewart Brand spends a considerable amount of time on this topic as he is involved in many of these efforts.
Two of these authors are also two of the creators of the Catala programming language, which is "a domain-specific programming language designed for deriving correct-by-construction implementations from legislative texts." (https://catala-lang.org/en/).
APL was originally created by Iverson as a notation used to teach mathematics and only became a programming language able to be executed by a computer around the time that (or shortly after) he published his book _A Programming Language_ [0] in 1962.
Even throwing away the “executable by a computer” part of APL and only considering it as a notation, APL can be powerful. Iverson gave a lecture, which was published as _Notation as a Tool of Thought_ [1] that contains a good discussion of what exactly makes a given notation “good”.
- Documents
-- <a folder for each employer>
-- <a personal folder>
- Repos
-- <a folder for each language>
I also make extensive use of a little rust tool I whipped up which tags file paths with user defined tags, which are then searchable: https://gitlab.com/zwick/genie
This allows me to quickly find all file paths that are tagged with <employer #1> for instance regardless of where they are all from within a terminal.
In previous embedded work, I've had to follow the MISRA C [0] guidelines, which I suspect are roughly similar to the JPL guidelines (but I can't get to the PDF at the moment due to the bad SSL cert).
> Two earlier efforts have most influenced the contents of this standard. The first is the MISRA-C coding guideline from 2004 [...]
Not just similar, but based on MISRA C!
MISRA C can be a total PITA though (I get why, but it doesn't make it any less annoying). Some well known storage products follow similar principles without being quite so stringent. It's quite a nice middle ground, and - if you are, err, detail oriented - can be a less aggravating experience than sloppy, higher level codebases (yes, Java, I'm looking at you mainly).
MISRA C is annoying mostly if you have to change the codebase to fit the standard. If you iteratively solve MISRA warnings they become second nature and you almost don't make them anymore.
What is annoying is the paperwork when you need a deviation. However that's kind of the point of the process. Make it annoying enough that people really think about whether the deviation is necessary.
At the same time it's only a coding standard. Not a panacea for all your coding issues. You can have 100% MISRA conformant spaghetti.
It does reduce the "shoot yourself in the foot" surface area a little bit though.
IMHO some of MISRA rules lead directly to hard to read/maintain code. Consider a function that:
1. opens a file
2. allocates enough memory to store the whole file
3. reads the file
4. return the allocated buffer on success or NULL on failure
You want to write it so it doesn't leak either memory or file handles whether successful or not (if successful ownership of the memory buffer is passed to the caller so it must not be freed in that case).
To be MISRA compliant you'd either end up with a "Christmas tree" of nested scopes or if-statements with extra && in them (pseudo C-code):
char *buf = NULL;
FILE *fh = fopen(...);
if (fh) {
if (success(fseek(fh, end))) {
long int sz = ftell(fh);
if (sz > 0) {
buf = malloc(sz);
if (buf) {
if (failed(fread(fh, buf))) {
report_error();
free(buf);
buf = NULL;
}
} else {
report_error();
}
} else {
report_error();
}
} else {
report_error();
}
fclose(fh);
} else {
report_error();
}
return buf;
However if you were allowed to use goto with a single exit-label the code would be much cleaner and easier to follow:
char *buf = NULL;
char *rv = NULL;
FILE *fh = fopen(...);
if (!fh) {
report_error();
goto exit;
}
if (fail(fseek(fh, end))) {
report_error();
goto exit;
}
long int sz = ftell(fh);
if (sz <= 0) {
report_error();
goto exit;
}
buf = malloc(sz);
if (!buf) {
report_error();
goto exit;
}
if (failed(fread(fh, buf))) {
report_error();
goto exit;
}
rv = buf;
buf = NULL;
exit:
if (fh) {
fclose(fh);
}
if (buf) {
free(buf);
}
return rv;
Actually it’s not the same, as using goto lets you have very natural reverse order cleanup at the exit of the function (widely used in the Linux kernel for example).
Which brings us back full circle to the point I was originally trying to convey: if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard.
Fortunately MISRA seems to have gotten back some sanity in the 2012 revision compared to the one the above JPL standard is based on.
>Which brings us back full circle to the point I was originally trying to convey: if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard.
Only if the "more convoluted and harder-to-read code" is worse than what the standard tries to avoid.
A standard that calls for not allocating memory dynamically for example might result in less elegant code than one that does, for example, but that's not a "clear failure" since that away it avoids the uncertainty and variable runtime performance that malloc brings.
I'm addressing the general claim here, that "if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard" -- not specifically where the particular no-goto rule was justified.
A standard can be perfectly valid and good in restricting things even if that forces programmers to write "less elegant code" -- as long as this is necessary to fulfil some other objective of the standard (e.g. easy formal verification or real-time behavior).
You must prove that this loop will terminate: All loops shall have a statically determinable upper-bound on the maximum number of loop iterations. It shall be possible for a static compliance checking tool to affirm the existence of the bound.
Too little karma to edit and fix indentation. Anyway given the above functions, think about adding support for only returning the buffer if the file contains a specific word. While certainly doable in both cases I would at least feel more uncertain editing the first without accidentally creating a bug...
> Most Misra software is embedded without dynamic allocation though
True, but I've seen enough MISRA code bases plagued with the "Christmas tree" layout even if dynamic memory allocation isn't allowed. This was just a generic example most people can relate to.
I just checked, and MISRA 2012 seems to allow goto again under certain preconditions (you have to have a label declared in the same function and it has to be in the same block). So actually you can do proper error handling again.
Still single return statement, which usually makes for more spaghetti.
Shoehorning an existing codebase into being MISRA compliant is utter hell. It's something you really need to design-in from the beginning.
Also for anyone in the audience who's going "ugh, MISRA..." -- the 2012 spec revision is a significant improvement on the 2004 version and cleans up a lot of the more troublesome rules.
Even if I'm not doing MISRA-required code, I still find myself sticking to its suggestions... "Allocate memory statically" is a really good one, especially on embedded systems.
I went to a planting a few years ago put on by this same group in Ann Arbor, MI at the Nichols Arboretum [0]. It was pretty inspiring to see a real living clone and hear David Milarch speak about the science and art of cloning these old growth trees. IIRC, the clones planted in Ann Arbor are from one of the Giant Sequoias at [1] in northern MI.
The "DIY with basic tools" approach of Sears extended well beyond houses. Sears also sold motorcycles [0] that came with a thick manual that gave instructions on how to do everything from assembling the motorcycle from the shipped pieces in the crate to fully disassembling and rebuilding the engine. I've restored a handful of them before, and they are a lot of fun to work on. They are simple enough that there aren't too many hurdles to get over, and they are always a good conversation starter when you're parked somewhere.
This hits close to home for me too, and I am as WASP-y as it gets.
Just over a year ago I was flying to the middle of US with some prototypes for an agriculural automation system in my checked luggage. Going through DTW and O'Hare to my final destination was fine and went without incident. On my way back, again with a checked luggage bag of protypes and tools, this little airport in northwest IA got evacauted and I was very forcibly questioned about why I was flying with these things.
What struck me was that the larger airports (DTW and O'Hare) couldn't have cared less, but this 5-gate airport in IA freaked out that somebody flying with three laptops in his carryon would also have a bag of tools and equipment.
The best part out of all of this was after everything was cleared up, I asked the head TSA person what I should do in the future to prevent getting searched and interrogated. His answer was "just open your bag and show the luggage agent what is in it." I still don't understand how that would help - I envision that the conversation would go something like "Hi, these look like pipe bombs. They aren't. You can trust me." and I would immediately be detained.
When I got out of the Army in the 90's, I had to fly back to America, and since I didn't trust the government's shipping contractor I took all of the guts out of my PC, stuck them in a carry-on bag, and went through security with it. The guy at the counter looked inside the bag and asked what it was. I told him it was a computer and he let me through. Oh, such an age of innocence!
I can only imagine the effect of an interrogation like that on a 14yr old. I was 24 and was completly drained by mine.
I was questioned by each of the TSA, the local sheriff, and the plane's pilot and an airline rep.
Three different interrogations all asking the same questions just to determine if I was going to be allowed to fly.
I also travel with custom imaging equipment that sometimes has exposed PCBs. My recommendation is to carry it on, so that you can open it and explain it. Twice I have approached the gate well ahead of my flight, and offered to show TSA the equipment. Both times they took only a cursory glance at it.
I'm surprised they don't just mandate the spectrogram swab on every piece of electronics that comes through, consumer or custom.
To be fair, your 'agriculural automation system' components likely could be used for an explosive device.
On the other hand, I once had an airport security agent delay me because I had a transparent purple Game Boy Color in my carry-on. He (an older Filipino gentleman) seemed genuinely confused about what it was. It was pre-9/11, coincidentally also in Texas.
https://www.weareasgods.film/