I'm getting misty-eyed over here. Seriously, I thought I was the only one.

I have heard almost no advice that's anywhere near actionable in our industry. The way I see it is that we have no objective ways to even talk about good code versus bad code (and forget all of the support tasks like "can we estimate this"; those require some objective understanding on how terrible the code happens to be).

We've got code smells. Like, the most primitive and "from your gut" sense. This for-loop makes my tummy feel bad.

It all feels like poetry to me.

The problem is if you take any actionable idea as law, there is a pendulum swing to the other side to the point that you need a counter actionable idea to reset it.

OOP started like that, as an initial concept it made a lot of sense. Try to force OOP into anything you have a problem. Functional Programming, is the counter to OOP design, but it also has problems.

Same is true to having short functions doing one thing vs abstracting too early. Our industry is filled with counter points.

Even the "recent" shift to microservices, taking to the extreme they create new problems that monoliths didn't have.

...this is one of my biggest struggles as a developer currently, conflicting ideas that all make sense and trying to figure out which one I should apply for a specific piece of code.

There are a number of agreed bad practises: long functions, deep nesting, obtuse identifiers, unrestricted use of gotos, global variables, no coding standard, premature optimisation, C macros, raw pointers...

False.

Bryan Cantrill (OS developer who used to work at sun microsystems) talks about how the C macros are great [1].

John Carmack talks about how long functions can be better than short ones [2].

Every piece of advice that I've heard has had a contradiction coming from a preeminent developer.

To be fair, yes, people do agree on bad practices. They are just often wrong. People agreeing that something is true doesn't make it that way.

[1] - I believe that he mentions that here however, I'm not sure. I have heard him mention it in more than one video. https://www.youtube.com/watch?v=LjFM8vw3pbU

[2] - http://number-none.com/blow/john_carmack_on_inlined_code.htm...

I remember reading John Carmack's comments a few years back and it kind of broke my coding style because it seemed like I did everything opposite of his suggestions.

I haven't recovered since. For anyone interested, here is my notes summary from various articles and videos from John.

### John Carmack

* Do-always, then inhibit or ignore strategy

* Common pattern for me: get first results with hacky code, then write a brand new and clean implementation with the lessons learned, so they both exist and can be cross checked.

* If a function is only called from a single place, consider inlining it.

* If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that.

* If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters.

* If the work is close to purely functional, with few references to global state, try to make it completely functional.

* Try to use const on both parameters and functions when the function really must be used in multiple places.

* Minimize control flow complexity and "area under ifs", favoring consistent execution paths and times over "optimally" avoiding unnecessary work.

Not false.

Sure there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

I often think there's an equal and opposite other side to that: Don't /make/ any rules unless you know what you are doing and able to justify them (and their scope of effectiveness).

I've recently had to work on a project controlled by someone who's swallowed "clean code" and a couple of C# style guides and now just unthinkingly applies what he thinks he's read. E.g: you are not allowed any comments in this codebase. No variable may be typed. Period.

Both extremes are.. not good.

> there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

Isn't this exactly the kind of vague advice that GP was talking about?

Perhaps, or perhaps it is a meta-rule, i.e. a rule about rules. Either way it is just obvious common sense IMO.

I find these actionable as well:

O - "Don't modify, extend instead."

I - "Don't group interfaces into a god object - separate them."

D - "Depend on abstractions not concrete implementations."

S is the most disputed but Uncle Bob occasionally clarifies (paraphrased, again): "Object definitions should be beholden to only one stakeholder group."

SOLID seems actionable enough to me... whereas Holub's article is a bunch of fluffy mothering statements.