A list of programming/computer science/software development terms that I have encountered in my research/work/readings. Some terms have a link to the wikipedia definition. I try to be more concise than them, and to explain the term as I understood it from all the sources I read.

Some satirical terms here are taken from the Coding Horror site. They may be satire but are used in the wild, so they are oficial.

B

Baklava Code: Code that has too many layers, and no matter how good an architecture you have, some layer leakage will start to apperar.

C

Closure: a function (or reference to a function) and a reference to all the environment (non-local variables) that are used by the function.

Conference-Driven Development: managing your project features and timeline so you are able to release in line with industry conferences.

D

Duck Typing: If it looks like a duck, quacks like a duck, then you can use it like a duck. so if you have an object that responds to a set of messages, then this is the type of object you have, regardless of class hierarchies and things like that. Duck typing allows polymorphism without inheritance, but may cause problems if the programmer has bad eyesight and what he saw was not a duck but a swan – that is, if the types used don’t actually implement the required set of messages. This can cause ugly run-time exceptions that don’t occur in statically typed languages.

F

First Order Function: a function which is not a High-order Function (See definition below).

Fixture: a set of objects required to run a group of unit tests. The fixture is usually initialized in a specially marked function before executing each unit test.

H

Heisenbug: a bug that changes (or disappears) every time you try to study it. The name come after the famous phisicist Werner Heisenberg who asserted that the act of observing an event automatically changes it.

Higgs-Bugson: a theoretical bug that is supposed to exist based on a number of events in the system and the knowledge that the programmers have, but it is very difficult (if possible) to reproduce because nobody know if it really exists and what really causes it.

Higher-Order Function: A function that receives a function as an argument or yields a function as its return value (or both). Used mostly in functional programming languages (but is possible to implement good ol’ C).

Hype-Driven Development: using a technology/platform because of the hype. To quote the source: “Just because others are “using” blockchain, you don’t have to use a blockchain”.

M

Mixin: a set of methods (maybe a class or a module or something else, depending on your language) grouped together that can be used to extend the functionality of existing classes. An abstract base class is a mixin. Mixins can also be seen as an interface that also implements its methods. I personally prefer adapter classes than mixins because the usage of mixins creates classes which have many many methods, making them harder to understand.

Mock: used (mostly) for testing purposes, a mock is an object that simulates the behavior of a given class, without really implementing it. Mock objects can be implemented manually (by subclassing the class and changing the behavior) or created using mocking frameworks (like EasyMock in java). Databases are a typical target for mocking – if you had to populate a real database for every unit tests they would take years for the tests to run, and would probably break very hard when you changed the database. Using a mock that behaves like the database, while it requires some coding, would be the solution.

P

Phoenix Server: A term coined by Martin Flower not a short time ago (at least from what I know). A Phoenix Server is a server that (like the mythological bird) is immortal and after it dies it is re-born from its own ashes. Serverwise, this means that your servers can be burned, deleted and broken, and when the server goes up again, it should restart itself, reconfigure itself and return to work with no human intervention. Phoenix servers are a MUST for mission critical systems, but today all web-based services cannot handle even the minimal timeline, so this theory should also be applied there.

R

Re-opening a class: in Ruby, you can change the behavior of a class anywhere in the program!, and this is called reopening. Let’s say you want to add a function to the String class called hello which returns “hello ” and the value of the string. No problem:

class String
  def hello
    "hello "+self
  end
end

And now:

>"Arieh".hello
=> hello Arieh


Cool but dangerous…

S

Spaceship Operator: . For a b returns -1 if a < b, 0 if a = b and 1 if a > b . Note that the notions of <, = and > are local to the particular language or implementation you are using and may not be intuitive some times.

Stringly Typed: using strings as your typing system, instead of using strong types, specifically enums. If your code if full of <code>if (someVar = “someString”)</code> it is probably stringly typed.

Y

Yoda Conditions: using if (constant == variable) instead of if (variable == constant) in boolean operators. For example, if you write if (true == networkAvailable) you are saying “If true is networkAvailable”, while writing (networkAvailable == true) is read as “If networkAvailable is true” which will be translated very fast in your head into “if the network is available”. The first phrase will just sound like Yoda speaking wise words to you but not really making sense. The practice of Yoda Conditions comes from the desire to minimize bugs by having the left-hand side of the condition be a constant, so if by any chance you tried to assign it a value instead of comparing, you would have received a compiler error. Now that compilers/IDEs are very smart and warn you of this it is not necessary. You should NEVER use it, since it makes your code very, VERY hard to read.