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...
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.
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.
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...