Sometime back I ran across a thread where folks talked about this programming style called “Space Shuttle style” that the Kubernetes codebase followed.

// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================
//
// This controller is intentionally written in a very verbose style.  You will
// notice:
//
// 1.  Every 'if' statement has a matching 'else' (exception: simple error
//     checks for a client API call)
// 2.  Things that may seem obvious are commented explicitly
//
// We call this style 'space shuttle style'.  Space shuttle style is meant to
// ensure that every branch and condition is considered and accounted for -
// the same way code is written at NASA for applications like the space
// shuttle.
//
// Originally, the work of this controller was split amongst three
// controllers.  This controller is the result a large effort to simplify the
// PV subsystem.  During that effort, it became clear that we needed to ensure
// that every single condition was handled and accounted for in the code, even
// if it resulted in no-op code branches.
//
// As a result, the controller code may seem overly verbose, commented, and
// 'branchy'.  However, a large amount of business knowledge and context is
// recorded here in order to ensure that future maintainers can correctly
// reason through the complexities of the binding behavior.  For that reason,
// changes to this file should preserve and add to the space shuttle style.
//
// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================

To be clear: I don’t follow the Space Shuttle style programming with my own code. However, I’ve noticed now that when I do comment my code, I’m a little more liberal with my explanations. It’s made me realize that commenting your code doesn’t necessarily always mean bastardizing it.

Originally, the work of this controller was split amongst three controllers. This controller is the result a large effort to simplify the PV subsystem.

However, a large amount of business knowledge and context is recorded here in order to ensure that future maintainers can correctly reason through the complexities of the binding behavior.

This is how I feel sometimes when people abuse abstraction. Yes, composition is important but long files are sometimes ok if it makes the code easier to comprehend by preventing that extra cognitive jump (required to first understand the name of the newly abstracted component).

From the Kubernetes source code.