Programming Practices – Are Default Values Good or Evil?

programming practices

The question about default values in general – default return function values, default parameter values, default logic for when something is missing, default logic for handling exceptions, default logic for handling the edge conditions etc.

For a long time I considered default values to be a "pure evil" thing, something that "cloaks the catastrophe" and results in a very hard do find bugs. But recently I started to think about default values as some sort of a technical debt … which is not a straight bad thing but something that could provide some "short term financing" get us to survive the project (how many of us could afford to buy a house without taking out the mortgage?).

When I say a "short term" – I don't mean – "do something quickly first and do refactor it out later before it hits the production". No – I am talking about relying on a hardcoded default values in a production software. Granted – it could cause some issues, but what if it only going to cause a single trouble in a whole year.

Again – I am talking about the "average" mainstream software here (not a software for a nuclear power station) – the average web site or a UI application for the accounting software, meaning that people lives are not at stake, nor millions of dollars.

Again, from my experience, business users would rather live with the software which "works somehow", rather then wait for a perfect one. And the use of default values helps a lot if you develop a software in a RAD style. But again – the longest debug sessions I have spent were because of the bugs introduced by a default value which either stopped being "a default" along the way or because a small subsystem has recently been upgraded and as a result of this upgrade it does not handle the default correctly (e.g. empty list vs null, or null string vs empty string).

So my question is – are the default values good or evil. And if they are a technical debt – how do measure up how much you can borrow so you can afford the repayments?

Best Answer

The concept of Convention over Configuration is impossible without sensible default values. The key word here is "sensible". The default values have to make sense for at least 80% (if not more) of all the uses of a library/service/framework.

General rules of thumb:

If a value is sensible for 80% or more uses, it needs to be a default value
If there are no values that are used for the majority of cases, do not use defaults.
Default values prevent stupid mistakes from the setup code. If the defaults are reasonable for most cases, fewer people mess with the working configuration.
Non-standard configurations are more visible when you use defaults.
Bad defaults are worse than no defaults.

Essentially, once you learn how the default configuration works, you can make educated decisions about how/when to do non-standard configurations.

Related Solutions

Programming Practices – Is Hardcoding Values in Applications Ever a Good Idea?

Yes, but do make it obvious.

Do:

use constants
use a descriptive variable name

Don't:

have any magic numbers floating around the code

Combinators in Programming – Practical Explanation

From a practical viewpoint combinators are kind of programming constructs that allow you to put together pieces of logic in interesting and often advanced manners. Typically using them depends on the possibility of being able to pack executable code into objects, often called (for historical reasons) lambda functions or lambda expressions, but your mileage can vary.

A simple example of a (useful) combinator is one that takes two lambda functions without parameters, and creates a new one that runs them in sequence. The actual combinator looks in generic pseudocode like this:

func in_sequence(first, second):
  lambda ():
    first()
    second()

The crucial thing that makes this a combinator is the anonymous function (lambda function) on the second line; when you call

a = in_sequence(f, g)

the resulting object a is not the result of running first f() and then g(), but it is an object that you can call later to execute f() and g() in sequence:

a() // a is a callable object, i.e. a function without parameters

You can similarly then have a combinator that runs two code blocks in parallel:

func in_parallel(first, second):
  lambda ():
    t1 = start_thread(first)
    t2 = start_thread(second)
    wait(t1)
    wait(t2)

And then again,

a = in_parallel(f, g)
a()

The cool thing is that 'in_parallel' and 'in_sequence' are both combinators with the same type / signature, i.e. they both take two parameterless function objects and return a new one. You can actually then write things like

a = in_sequence(in_parallel(f, g), in_parallel(h, i))

and it works as expected.

Basically so combinators allow you to construct your program's control flow (among other things) in a procedural and flexible fashion. For example, if you use in_parallel(..) combinator to run parallelism in your program, you can add debugging related to that to the implementation of the in_parallel combinator itself. Later, if you suspect that your program has parallelism-related bug, you can actually just reimplement in_parallel:

in_parallel(first, second):
  in_sequence(first, second)

and with one stroke, all the parallel sections have been converted into sequential ones!

Combinators are very useful when used right.

The Y combinator, however, is not needed in real life. It is a combinator that allows you to create self-recursive functions, and you can create them easily in any modern language without the Y combinator.

Best Answer

Related Solutions

Programming Practices – Is Hardcoding Values in Applications Ever a Good Idea?

Combinators in Programming – Practical Explanation

Related Topic