Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information.
I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenated together, how far beyond that you take things runs into diminishing returns. However at a minimum formatting changes shouldn’t regularly complicate doing a diff.
But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language.
If an architect from a different country did that blueprint, I would bet that it would be significantly different from the blueprint you have.
Software Engineering doesn't have a problem with country borders, but different languages would require different standards and conventions. Unless you can convince everyone to use the same language (which would be a bad idea; CRUD apps and rocket systems have different trade-offs), I doubt there could be an industry-wide standard.
The only software standard that I'm reasonably familiar with is https://en.wikipedia.org/wiki/IEC_62304 which is specific to Medical Devices. In a 62304-compliant project, we might be able to do something like your example, but it could take a while. OTOH, I'm told that my Aviation counterparts following DO-178 would almost certainly be able to do something comparable.
It is going to be very industry dependent, where "industry" means aviation, or maritime, or railroad, or Healthcare, etc... Just "software" is too general to be meaningful these days.
It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time. We're stuck in endless fights about what is cleaner or more readable or more maintainable way of abstracting / passing errors / sizing functions / naming variables... and so on, because the industry still misses the actual answer: it depends on what you're doing at the moment. There is no one best representation, one best function size. In fact, one form may be ideal for you now, and the opposite of it may be ideal for you five minutes later, as you switch from e.g. understanding the module to debugging a specific issue in it.
We've saturated the expressive capability of our programming paradigm. We're sliding back and forth along the Pareto frontier, like a drunkard leaning against a wall, trying to find their way back to a pub without falling over. No, inventing even more mathematically complex category of magic monads won't help, that's just repackaging complexity to reach a different point on the Pareto frontier.
Hint: in construction, there is never one blueprint everyone works with. Try to fit all information about geometry, structural properties, material properties, interior arrangement, plumbing, electricity, insulation, HVAC, geological conditions, hydrological conditions, and tax conditions onto a single flat image, and... you'll get a good approximation of what source code looks like in programming as it is today.
Code uses text, sometimes even natural-language prose, but isn't like "books and writing". It has to communicate knowledge, not feels. It also ultimately have to be precise enough to give unambiguous instructions to a machine.
In this sense, code is like mathematical proofs and like architectural blueprints, which is a different category to drawings, paintings and literature. One is about shared, objective, precise understanding of a problem. The other is about sharing subjective, emotional experiences; having the audience understand the work, much less everyone understand it the same way, is not required, usually not possible, and often undesirable.
Whoever drew your blueprints knew they would be needed beyond getting the house up. What would the equivalent perspective and effort for software engineering be?
Some people still argue over autoformatter parameters, but then people will always find a bike shed to argue about.
With clang-format & co. on Save plus possibly a git hook this all went away. It might not always be perfect (which is subjective anyway) but its so worth it.
I highly recommend it though, especially if you worked for a long time at one company and are used to a specific way of writing code. Or if you like tabs instead of spaces...
If the code needs to be reformatted, this should be done in a separate commit. Fortunately, there are now structural/semantic diff tools available for some languages that can help if someone hasn't properly split their formatting and logic changes.
What we should have instead is syntax-aware diffs that can ignore meaningless changes like curly braces moving into another line or lines getting wrapped for reasons.
https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
These diffs already exist (at least for some languages) but aren't yet integrated into the standard tools. For example, if you want a command line tool, you can use https://github.com/Wilfred/difftastic or if you are interested in a VS Code extension / GitHub App instead, you can give https://semanticdiff.com a try.
The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it doesn’t get build and stays a certain way.
I agree that a house is a bad analogy, for your reasons and because you can "live" in software that as a building would not be fit for human habitation.
This is the exact trap I'm describing. It sounds very reasonable, but how is it not prediction when you're asking people to "recognize the <future> consequences of each choice"? You have very little to no understanding of the context, environment or application of today's creations. Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.
> Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.
Those are solutions to real problems. The real issue is the cargo cult, aka "Google is doing it, let's do it too". If you don't have the problem, don't adopt the solution (which always bring its own issues). It's always a balancing act as there is no silver bullet.
Did anyone claim otherwise? Besides, I imagine bridges aren't rebuilt every week -- poor blueprints can only cause a finite amount of pain.
There's such a school?? Seriously??
Imagine if Blueprint A used imperial units while others used metric units.
That's what inconsistent code style does to you.
Maybe not at the same level, but code organization is also a design.
I don’t care that much about the exact linter rules applies (but I do prefer blue, hmm, nooo). But getting rid of merge conflicts that come from lake of common linter rules, this is a great pipeline process improvement, and this is some kind of code contribution pipeline design.
This is incredibly important.
This is the kind of stuff that prevents shit like half the team using metric and the other half thinking they're imperial, or you coming up with the perfect design, but then the manufacturer makes a mirrored version of it because you didn't have the conventions agreed upon.
This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if it meets the requirements in functionality. You don't have time for that stuff, you are too busy trying to make this one person happy by turning an if else into a ternary and the end of sprint is a day away.
Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me.
The example about if/else vs ? : is pretty damning though.
If/else vs ternaries is something where consistency is a lot less important, but if you know that a team member has a strong preference for one over the other and you think it's unimportant then you should just write it how they prefer to begin with. Fight over things you think are important, not things that you think don't matter.
I worked with a guy where you would try to predict what he would bitch about next. In this example, you would write it as a ternary so you don't have to hear about it ... and he'd suggest it be an if-else statement.
Nobody fucking cares which one it is; is it readable? That's the real question. Your preference of which version of "readable" it is only applies when you are the author. If you're that picky about it, write it yourself. That's what we eventually did to that guy after the team got sick of it. Anytime he'd complain about something like that, we would invite him to write a PR to our PR, otherwise, get over it. Then, we would merge our PR before he could finish.
He eventually got fired for no longer able to keep up with his work due to constantly opening refactor PR's to the dev branch.
> "When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through."
The same is true in software when a developer inherits a codebase.
Those signs of quality turn into longevity, even when they face away from the user.
That is not to say I'm one of those people who need a specific code style to have their weird brain satisfied. But not using a linter/autoformatter at all [when available] in 2025 sounds like the opposite of "work smart, not hard"
Code style though, I do agree isn’t worth stressing about. I do think you may as well decide on a linter/style, just so it’s decided and you can give it minimal energy moving forward.
I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.