GitHub - molvqingtai/The-Absolute-Code: The Absolute Code: In human-readable code, express the same behavior and constraints with the minimum code. · GitHub
/" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
/;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
molvqingtai
The-Absolute-Code
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
master
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>24 Commits<br>24 Commits
LICENSE
LICENSE
README.md
README.md
View all files
Repository files navigation
The Absolute Code
Coding agents can produce plausible code quickly. They also add helpers, wrappers, fallbacks, compatibility paths, and tests for code that should not exist. Reviewers need a standard that does not collapse into taste.
The only rule of The Absolute Code: minimum code.
If the same behavior and constraints can be expressed with less code, the extra code must go.
Convergence
How do we measure good code?
By the minimum human-readable code that expresses the same behavior and constraints. Good code is also physically minimum code.
If code satisfies the requirement and constraints, contains nothing extra, and remains readable to humans, then in a physical sense it is human-readable minimum code.
That is the physical law behind good code. Clean, elegant, maintainable, and well-designed are partial names for it. Abstractions, boundaries, structures, libraries, and models start from different problems, but when they are right they converge on this same shape.
This essay calls that shape minimum code. We did not invent it. We recognized a physical law already present in good code.
Because the shape is physical, it can be tested: keep behavior, constraints, and readability fixed, then remove everything that can go.
Minimum code is not the fewest characters or the shortest diff. It keeps every necessary boundary, guarantee, and failure state.
Reduction Test
What can be deleted without changing behavior?
Hold behavior, constraints, and human readability fixed. Then ask what can disappear.
Can state be derived instead of stored? Can a branch move to the boundary that owns the difference? Can a wrapper call the primitive directly? Can invalid data become impossible earlier? Can a trusted library replace this mechanism? Can an abstraction disappear because the concept has not appeared?
If yes, the implementation has not reached minimum code. If no, the remaining code should point to a requirement, boundary, guarantee, failure state, or domain rule.
Reduction is not isolated deletion. It reshapes the model until nothing unnecessary remains.
Abstraction
When should I abstract this?
Abstract only when it removes more code and concepts than it adds.
An abstraction earns its place when it deletes repetition, names a stable domain concept, hides detail callers should not know, or puts a boundary where it belongs. Then the rest of the system carries less.
An abstraction that only forwards, wraps, renames, or splits direct logic across files is extra code. The reader now has more names, jumps, and places for behavior to hide. Wait until the program has proved the concept exists. Until then, direct code is stricter.
OOP, functional programming, patterns, and libraries are implementation choices, not goals. Use whichever form preserves behavior, constraints, types, safety, errors, and verifiability with the least necessary human-readable code.
Boundaries
Why does the same bug need fixing in three places?
Repeated repair code usually means the boundary is wrong.
Fallbacks, normalization, and compatibility layers belong where uncontrolled shapes enter: external input, migrations, third-party APIs, URL parameters, forms, imported data. Boundary code translates outside shapes into the internal model.
After that translation, repeated normalization means the model is still leaking. A fallback copied across callers turns an error shape into a supported path. Copied state becomes a second truth and a future stale-value bug.
Minimum code pushes data into the right model early, keeps repairs at the edge, and...