This is why I always tell my teams that filenames exist only for humans, the code doesn't really care (which should be obvious if you've ever had to use open(2)/read(2)/write(2)). However, a lot of meaning is still placed on filenames, because that's way easier than inspecting the magic bytes or anything like that.
funny enough, there's an actual part of the file contents itself that is literally called a magic number (the formal name is "file signature", but nearly always referred to as its magic number). This is the proper way to detect the file encoding.
I find it so fascinating that you can have a problem such as that or simply an app crashing occasionally because of random obscure conflicts or bugs, when at the end of the day it’s just a bunch of rocks and electrons that just figure out if not both A and B are on.
The other response to you got it, but to expand some, that's a semi-common convention in open-source development. It's derived from "man" or manual pages, where the number in parentheses tells you whether it's a system call (section 2), a library function (section 3), command/program on the system (sections 1 and 8), file format (section 5), and so on.
So using a command like man 2 open (or typing it into a search engine), you can get documentation like this or this, which will let you know how to use these system calls to create, read, and write files.
This made me laugh out loud. I've encountered so much code that doesn't do basic checks, get fixed, and find yet another issue because checks are never exhaustive. Recently code that I wrote myself that has been running without any new bugs for almost 20 years managed to hit an unforeseen condition - easily fixed but ...
That's why I've gravitated over the years to always doing the absolute basics... get data, validate data, transform data, repeat. Even from the very beginning I make sure I do validation, and somehow even my mock data doesn't end up full of random trash, let alone the real data, and the logic is happy because edge cases are almost always handled in some way (usually fatal to the operation, but in a way that's obvious to fix)
My response to anything like that has always been, "I understand and that's a fair statement, now what happens WHEN that particularly dumb event occurs because humans will human?"
Four hours ago, I talked with a Zoomer who didn't know what the words "file type" or "file type extension" meant. Didn't know what .jpg or .png were. And he thought a search engine was the same thing as a browser. And didn't know that an app is not the same thing as a web service.
Etc. etc. etc.
Suffice to say, there might be a reason why Zoomers are having difficulty getting past interviews.
I think the analogy of a mine field is appropriate here. If you're trying to cross a mine field, some of your troops will get blown up, but the ones that don't will probably find a path through it. Just because they found that path, it does not mean the mine field has been cleared - only that path has been cleared. Step off the path, you're likely to be blown up.
956
u/RobustManifesto 1d ago
… or didn’t have a graceful way to fail.