The Performance Cost of Clean Code: How Following Clean‑Code Rules Can Slow Down Your Program

Writing "clean" code is a repeatedly‑taught programming recommendation, especially for beginners, but many of the rules do not affect runtime performance and are hard to evaluate objectively.

Some clean‑code rules, however, can be measured because they directly influence execution speed. By extracting the rules that actually affect code structure, the author identifies a handful of guidelines: use polymorphism instead of if/else or switch , hide object internals, keep functions small, make each function do one thing, and apply the DRY principle.

To test the impact, a hierarchy of shape classes ( shape_base , square , rectangle , triangle , circle ) is implemented with a virtual Area() method. A loop sums the areas of many shapes using virtual calls, both in a straightforward version and an unrolled version ( TotalAreaVTBL and TotalAreaVTBL4 ).

class shape_base {
public:
    virtual f32 Area() = 0;
};
class square : public shape_base {
public:
    square(f32 s) : Side(s) {}
    virtual f32 Area() { return Side*Side; }
private:
    f32 Side;
};
// rectangle, triangle, circle definitions omitted for brevity

f32 TotalAreaVTBL(u32 ShapeCount, shape_base **Shapes) {
    f32 Accum = 0.0f;
    for (u32 i = 0; i < ShapeCount; ++i) {
        Accum += Shapes[i]->Area();
    }
    return Accum;
}

Running this code once (cold cache) and repeatedly (warm cache) shows that the clean‑code version requires about 35 loop iterations per shape, while a more "old‑school" approach—using an enum and a switch to compute area—reduces the loop count to roughly 24, a 1.5× speed improvement.

The switch‑based version is then replaced by a table‑driven implementation that stores per‑shape coefficients in a constant array, eliminating the switch entirely. This change yields a ten‑fold speedup over the polymorphic version and a fifteen‑fold improvement over the original clean‑code approach.

enum shape_type { Shape_Square, Shape_Rectangle, Shape_Triangle, Shape_Circle, Shape_Count };
struct shape_union { shape_type Type; f32 Width; f32 Height; };

f32 GetAreaSwitch(shape_union s) {
    switch (s.Type) {
        case Shape_Square:   return s.Width * s.Width;
        case Shape_Rectangle:return s.Width * s.Height;
        case Shape_Triangle: return 0.5f * s.Width * s.Height;
        case Shape_Circle:   return Pi32 * s.Width * s.Width;
        default: return 0.0f;
    }
}

const f32 CTable[Shape_Count] = { 1.0f, 1.0f, 0.5f, Pi32 };

f32 GetAreaUnion(shape_union s) {
    return CTable[s.Type] * s.Width * s.Height;
}

Further experiments add a second virtual function ( CornerCount() ) and compute a corner‑weighted area, showing that the performance gap widens (up to 20‑25× slower for the clean‑code version). The author argues that as code becomes more complex, the penalties of clean‑code rules increase dramatically.

In conclusion, while clean‑code guidelines may improve readability and maintainability, they can cause severe performance regressions—sometimes equivalent to a decade of hardware progress—especially in performance‑critical domains such as game engines or high‑performance computing.