4 ms·

I don't think it is possible to state a general list of priorities such like this on all source code and all contexts. What is not apparent here is the context

I don't think it is possible to state a general list of priorities such like this on all source code and all contexts. What is not apparent here is the context in which these priorities were stated. I could easily argue that maintainability (both reading and writing) is more important than runtime performance in any other given context. What would be interesting is a more elaborate discussion of the priorities based on the context (which is unknown in this case).

stinos 9y ago
Very good point. While all of these guidelines are spot on, I'll also usually favor maintainability/readability (as in proper combination of applying standard Good Practices and design patterns) over anything else, if context allows. Then again, I noticed since C++11 and beyond there is much less of a trade-off between maintainability/readability and runtime performance than there used to be. Might also be compilers getting better, and hardware in general somewhat faster. The latter also being why I start to care less about compile-time performance.
jandrewrogers 9y ago
One way of looking at the priorities is through the lens of "how difficult will it be to address these topics after the product ships?", with all of the inertia that entails. For example, most runtime performance is fundamentally architectural. Once you ship an architecture it is nearly impossible to change it in practice. You rarely get a second chance to do this correctly. Correctness can be particularly insidious if the code behaves well enough to use. There are many examples of incorrectness that became a "feature" after it shipped because users started exploiting the side-effects of incorrectness in their own applications, making it very difficult or impossible to properly address the underlying broken-ness. A lot of code spaghetti is the product of a janky feature implementation that has some incorrect behavior that needs to be supported indefinitely to keep users happy. (This is what I always fear most when developing software.) Compile times are a partly a side-effect of architecture but in practice you can often make large improvements without materially altering the design of the software. With minimal thoughtfulness in the software design, you can push this off until it really becomes painful without losing the ability to change it. And so on. Readability and writability are among the easiest things to change after the fact.

stinos 9y ago

Very good point. While all of these guidelines are spot on, I'll also usually favor maintainability/readability (as in proper combination of applying standard Good Practices and design patterns) over anything else, if context allows. Then again, I noticed since C++11 and beyond there is much less of a trade-off between maintainability/readability and runtime performance than there used to be. Might also be compilers getting better, and hardware in general somewhat faster. The latter also being why I start to care less about compile-time performance.

jandrewrogers 9y ago

One way of looking at the priorities is through the lens of "how difficult will it be to address these topics after the product ships?", with all of the inertia that entails. For example, most runtime performance is fundamentally architectural. Once you ship an architecture it is nearly impossible to change it in practice. You rarely get a second chance to do this correctly. Correctness can be particularly insidious if the code behaves well enough to use. There are many examples of incorrectness that became a "feature" after it shipped because users started exploiting the side-effects of incorrectness in their own applications, making it very difficult or impossible to properly address the underlying broken-ness. A lot of code spaghetti is the product of a janky feature implementation that has some incorrect behavior that needs to be supported indefinitely to keep users happy. (This is what I always fear most when developing software.) Compile times are a partly a side-effect of architecture but in practice you can often make large improvements without materially altering the design of the software. With minimal thoughtfulness in the software design, you can push this off until it really becomes painful without losing the ability to change it. And so on. Readability and writability are among the easiest things to change after the fact.