Glossary of coding coding and software jargon

Athens test

When a code runs from start to finish (compiled or script) without throwing an error, it passes the Athens test. This has no bearing on whether the code is performing the actual function it was designed for - it just means it is capable of executing without failure. For etymology, consult Steve Westenbroek :)

Boat anchor

Something obsolete, useless, and cumbersome – so-called because metaphorically its only productive use is to be thrown into the water as a boat mooring.

Code smell

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology. … It is also a term used by agile programmers.

Continuous integration (CI)

A development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests.

Cruft

A jargon word for anything that is left over, redundant and getting in the way. It is used particularly for defective, superseded, useless, superfluous, or dysfunctional elements in computer software.

Dogfooding

Eating your own dog food, also called dogfooding, occurs when an organization uses its own product. This can be a way for an organization to test its products in real-world usage. Hence dogfooding can act as quality control, and eventually a kind of testimonial advertising. Once in the market, dogfooding demonstrates confidence in the developers’ own products. In software development, this means using the code from a user’s point of view.

DRY don’t don’t repeat yourself.

God object

In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.

Kludge

A kludge or kluge (/klʌdʒ, kluːdʒ/) is a workaround or quick-and-dirty solution that is clumsy, inelegant, inefficient, difficult to extend and hard to maintain.

Lint

Lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. The term originates from a Unix utility that examined C language source code.

lmgtfy

Let me Google that for you. https://lmgtfy.com/

Minimum viable product

A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development. Gathering insights from an MVP is often less expensive than developing a product with more features, which increases costs and risk if the product fails, for example, due to incorrect assumptions.

Munging

Verb (used with or without object), munged, mung·ing. Computer Slang. To manipulate (raw data), especially to convert (data) from one format to another: the munging of HTML content.

PEBKAC

Problem exists between keyboard and computer. see also RTFM

REPL

Read-Eval-Print Loop

RTFM

Read the f—ing manual.

Software regression

A bug that makes a feature stop functioning as intended after a certain event (for example, when features or code are added or refactored). One goal of testing is to prevent software regression.

Stranded development

When code development branches in different directions that are further developed by not re-integrated with the main branch. Can lead to duplication of effort and makes maintenance difficult.

Technical debt

Technical debt (also known as design debt or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. [JRR: Seems like there should be a corresponding inverse, say, Technical Surplus: implied cost of over-engineering the solution from the start.]

Test-driven development (TDD)

A software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements. In the context of scientific programming, the idea is to start new code development with a test function that describes what needs to be done, and a small piece of test data that mimics the (large) real dataset that needs to be processed. The new code (usually a function) can then be written and tested rapidly against the test data set (via the test function). When the test finally passes, the new code can be run with the real dataset. This can greatly speed development (faster runtimes) and when the code is developed, a test is already in place to prevent future regressions to the code when new features are added.

“You aren’t gonna need it” (YAGNI)

A principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. XP co-founder Ron Jeffries has written: “Always implement things when you actually need them, never when you just foresee that you need them.”