"Software development is an art, not a science" Yeah we all went through that naive phase at some point. It is not art, it is a craft and it is engineering. You can apply population studies on source code and then conclude what practices that lead to bugs. This was already done in the 1990s by Les Hatton among others, who among other things wanted to bust the old myth that "software is art" (it was already old in the 1990s). His conclusions as documented in the book Safer C, which in turn inspired the MISRA C guide lines, were it was demonstrated that you can improve software quality considerably by sticking to a safe subset of the programming language. Despite criticism against it (by Les Hatton himself even), MISRA C was one of the more revolutionary things in safety-related software during the 2000s. By using a safe subset, coding standards and static analysis, one could drastically reduce the amount of bugs in software. All science and engineering, no art in sight.

I'm not talking about "cleverness" in the sense recognized as a Bad Thing by experienced developers. Quite the opposite. I'm talking about things like recognizing that "cleverness" is bad. This kind of wisdom only comes from experience. Unless something has changed since I was in school, they don't even try to teach it.

Consider it a "naive phase" if you want. The bottom line is that I consistently produce results where "educated" developers don't. And I've been doing it for longer than the average developer has been in the biz.

The point is that certain ways of writing programs are bad and it can be proven scientifically, beyond opinions and personal believes. You take a misbehaving program and track down the root cause. If you do that a million times on a million programs, bad practices emerge as hard evidence. For example writing if(x) do_stuff(); has proven to be dangerous and bad practice - the safe and correct way to write code is if(x) { do_stuff(); }. I used to subscribe to the former style but has abandoned it, because this is not opinions, this is empirical hard evidence. If you use the former style you will eventually write extra bugs because of it. There's no "artistic freedom" or "room to express one self" in engineering. There must be a reason why you write code in a certain way - an engineer requires this, while an "artist" needs to rationale to justify their decisions. This is why construction engineers are allowed build bridges but artists are not.

In fact the whole problem with SO's "opinion-based" close reasons is that they think that good program design is a matter of personal, subjective opinions. It is not that, it is not art. There are correct ways proven in use, such as object-orientation which has proven to be the best known way to design large and complex programs while keeping them maintainable and letting them scale further. And that's exactly why we need to make such questions on-topic: so that those with extensive experience of program design can share their experience of using wildly recognized good practices and design patterns.

I don't believe it has been or can be "proven scientifically." The studies reveal correlations. Understanding why certain things correlate with bugs is more important than mindlessly avoiding those things. For example, sometimes testing floats for equality is exactly the right thing to do.Thinking programs must be written a certain way leads to over-engineering. It's analogous to how novice developers explicitly implement design patterns. Design patterns are descriptive, not prescriptive. Their presence is often subtle. One of the code smells I look for when I join a project is classes named after design patterns.

I think we agree more than disagree. And FWIW, I share your opinion of OOP. The current generation of developers hates OOP because they don't understand it, because their professors never understood it. Even when OOP was the buzzword du jour, only a small minority ever really grokked it.

Kevin Krumwiede‭ If you have a "missing braces" bug, you can pretty much immediately tell if it was intentional, most often you got fooled by the indention. At the same time it is very hard to come up with a rationale for why you would skip braces. ("I don't like typing" ought to be the worst rationale ever for a programmer - programming is all about typing.) Some subjective arguments about keeping the code more compact are pretty light versus the sheer amount of severe bugs that the style is known to produce. Similarly, "hacking away" without an explicit coding style document is dangerous as well and simply not professional. Unless you are maintaining some existing project, where it will be wise to follow the conventions already used in the code base, even though they are well-known bad practices (cough hidingpointersbehindtypedef cough winapi cough). Everyone doing the same thing consistently = engineering. Everyone coding away like headless chickens = art.