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...
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...
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'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.
Isn't this exactly the kind of vague advice that GP was talking about?
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.