htmx/www/content/essays/prefer-if-statements.md
William Jackson 6d39919b99
Essay descriptions (#3154)
* Add description to architectural-sympathy

And fix some typos

* Add description to codin-dirty

* Add description to complexity-budget

* Add description to does-hypermedia-scale

* Add description to future and fix date

* Add description to hateoas

* Add description to how-did-rest-come-to-mean-...

* Add description to htmx-sucks

* Add description to hypermedia-apis-vs-data-apis

* Add description to hypermedia-clients

* Add description to hypermedia-driven-applications

* Update hypermedia-friendly-scripting.md

* Update hypermedia-on-whatever-youd-like.md

* Update is-htmx-another-javascript-framework.md

* Update locality-of-behaviour.md

* Update lore.md

* Update mvc.md

* Update no-build-step.md

* Update prefer-if-statements.md

* Update rest-copypasta.md

* Update right-click-view-source.md

* Update spa-alternative.md

* Update splitting-your-apis.md

* Update template-fragments.md

* Update rest-explained.md

* Update two-approaches-to-decoupling.md

* Update vendoring.md

* Remove double-quote characters from descriptions

* Add description block to demo.html

* Update view-transitions.md

* Update web-security-basics-with-htmx.md

* Update webcomponents-work-great.md

* Update when-to-use-hypermedia.md

* Update why-gumroad-didnt-choose-htmx.md

* Update why-tend-not-to-use-content-negotiation.md

* Update you-cant.md

* Fix description for htmx-sucks

* Use `authors` built-in variable

Instead of the custom `author` taxonomy

* Descriptions and typos in interviews

* That double word is actually correct
2025-01-29 10:53:42 -07:00

5.0 KiB
Raw Blame History

+++ title = "Prefer If Statements To Polymorphism..." description = """
In this collection of tweets, Carson Gross explores unconventional programming principles, including favoring if
statements over polymorphism, minimizing abstractions, and prioritizing practical, implementation-driven
development. He challenges traditional software design norms, advocating for simplicity, locality, and utility over
complexity and abstraction.""" date = 2024-12-07 updated = 2024-12-07 authors = ["Carson Gross"] [taxonomies] tag = ["posts"] +++

Or, Watching Myself Lose My Mind In Real Time...

"Invert, always invert." --Carl Jacobi, by way of Charlie Munger

  • If Statements

    prefer if statements to polymorphism

    whenever you are tempted to create a class, ask yourself: "could this be an if statement instead?"

  • The Closed/Closed Principle

    In grug-oriented programming, the closedclosed principle (CCP) states "software entities (classes, modules, functions, etc.) should be closed for extension, but also closed for modification"

    they should just do something useful man

  • The Minimize Abstractions Principle

    The Minimize Abstractions Principle (MAP) is a computer programming principle that states that "a module should minimize the number of abstractions it contains, both in API and in implementation. Stop navel gazing nerd."

  • The Try It Out Substitution Principle

    The "Try It Out" Substitution Principle states that you should try something out and, if that doesn't work, think about why, and substitute something else for it instead.

    It is common to need to substitute multiple things to hit on the right thing eventually.

  • The Useful Stuff Principle

    The Useful Stuff Principle states that entities must depend on useful stuff, not overly abstract nonsense. It states that a high-level module can depend on a low-level module, because that's how software works.

  • Dependencies

    The The Existence of Dependencies Is Not An Excuse For Destroying The Codebase Principle states that the existence of dependencies is not an excuse for destroying the codebase

  • Abstraction Budget

    consider giving your developers an abstraction budget

    when they exhaust that budget & ask for more, tell them they can have another abstraction when they remove an existing one

    when they complain, look for classes with the term "Factory", "Lookup" or "Visitor" in their names

  • Fewer Functions

    if your function is only called in one place, consider inlining it & reducing the total number of method signatures in your module, to help people better understand it

    studies show longer methods have fewer bugs per line of code, so favor longer methods over many smaller methods

  • "God" Object

    consider creating "God" objects that wrap a lot of functionality up in a single package

    consumers of your API don't want to learn 50 different classes to get something done, so give them a few that provide the core functionality of your module with minimal fuss

  • Copy & Paste Driven Development

    copy&paste driven development is a development methodology where, when you need to reuse some code but in a slightly different manner, you copy & paste the code & then modify it to satisfy the new requirements

    this contrasts with designing an elaborate object model, for example

  • Implementation Driven Development

    implementation driven development is a development methodology where you first explore various implementations of your idea to determine the best one, then add tests for it

    no test code may be written without first having some implementation code to drive that test

  • Mixing Concerns

    Mixing of Concerns is a design methodology whereby "concerns" of various kinds are mixed into a single code unit. This improves locality in that code unit by placing all relevant logic within it. An example of this is hypermedia, which mixes control & presentation information.

  • Macroservices Architecture

    a macroservice architecture revolves around "macroservices": network-deployed modules of code that provide a significant amount of functionality to the overall system

    by adopting a macroservice-based architecture you minimize deployment complexity & maximize resource utilization

  • Sorry

    kinda had a manic break last night my bad