Hacker News Reader

Comment by Verdex | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com