Taro Codes

Code Smell

Code that "smells bad" — somehow exhibits a symptom of what could become a serious problem if left untreated.

Apparently coined by Massimo Arnoldi, founder of Lifeware, and popularized by Kent Beck:

[...] my friend Massimo Arnoldi used the analogy of “smell”. Food might still be okay to eat if it smells bad but smelling bad is a warning. It’s also a warning of future problems. If it smells bad today it is going to be poison tomorrow.

See https://tidyfirst.substack.com/p/code-smells.

Spaghetti Code

Code that is all tangled — ejecution jumps from one place to another, rather than reading like prose, which makes it hard to follow and work with.

Event Sourcing

See Event Sourcing and Change Data Capture.

Change Data Capture

See Event Sourcing and Change Data Capture.

Frobnicate

As a verb, "frobnicate" or "frob" connotes aimless manipulation, as in "randomly trying changes without much thought, hoping to land on a solution by chance".

Derived from "frobnitz", a 100% made-up word that had no clear meaning to begin with, and, even then, people somehow misused it.

See http://zvon.org/comp/r/ref-Jargon_file.html#Terms~frobnicate, https://en.wiktionary.org/wiki/frobnitz.

Unit Test

I argue there's no single definition of "Unit Test" because nobody can agree con what a "unit" is.

Nevertheless, in my experience, people tend to refer to tests as "unit tests" when they are either testing a pure function or preventing any and all IO from happening by using mocks.

Since mocking is a code smell, the only acceptable unit is a pure function, which is why I favour the term "Pure Test".

See https://martinfowler.com/bliki/UnitTest.html.

Pure Test

This is what I call a test that tests a pure function.

I intentionally avoid the term "unit test" because it carries too much baggage and has no universally-agreed-upon definition.

Software Archeology

Navigating a code base that is old, largely or completely undocumented, unknown to current members of the team / organization / company, and still relevant.

See wikipedia:Software_archaeology.

Code Spelunking

Similar to software archeology, but not necesarilly implying the code base is "legacy", in a mostly abandoned state.

I learned this from Aldo Funes, in 2022. The oldest reference I can find is this paper from 2003.

Sybil Attack

In plain English: generally, nothing stops you from creating multiple accounts for a service.

This is a problem in voting / reputation systems — particularly, decentralized ones. There is no way to force one-vote-per-person if accounts aren't tied to people outside the system.

See wikipedia:Sybil_attack.

Protocol Ossification

The tendency of implementation bugs to make it harder to change a protocol.

See https://blog.cloudflare.com/bootstrap-mtc/.

Stringly Typed

Lovely pejorative pun on "strongly typed", shaming the use of untyped magic strings to drive behaviour.

TypeScript largely solved this with string literals because it's absolute magic, but no other mainstream language handles this situation well.

Why do this, which is begging for bugs?

function frobnicate(how) {
  if (how === 'a lot')
    doSomething()
  else if (how === 'not too much, please')
    doSomethingElse()
}

When we could actually use types:

enum HowMuch {
  ALot,
  NotTooMuchPlease,
}

function frobnicate(how: HowMuch) {
  if (how === HowMuch.ALot)
    doSomething()
  else if (how === HowMuch.NotTooMuchPlease)
    doSomethingElse()
}

With TypeScript you could do the following:

function frobnicate(how: 'a lot' | 'not too much, please') {
  if (how === 'a lot')
    doSomething()
  else if (how === 'not too much, please')
    doSomethingElse()
}

This is not ideal, but makes sense if you're getting the string literal from outside your system (say, in the response of some API call) and can't afford or don't want a small translation layer, or if you're adding TypeScript to a legacy code base that already suffers widespread use of stringly typing.

See https://wiki.c2.com/?StringlyTyped.

Boilerplate

Repetitive code that generally isn't the essence of what you're building, but is required by a framework / runtime / language.

This code is usually repetitive and boring, and tends to get copy-pasted a lot.

See https://buttondown.com/hillelwayne/archive/why-do-we-call-it-boilerplate-code/.