Explicit Versus Implicit — The Cost Of Implicitness in Programming Comprehension

JavaScript Throwable Functions

In JavaScript, we have no way of signaling if a given function will throw or not. This is the implicitness of calling a function.

// will it throw? Idk
type SomeFunction = (onError: (err) => void, onSuccess: (res) => void) => void;
type SomeFunction = () => Maybe<Result>;

React’s useEffect

React’s useEffect is an example of the drawback to implicitness. Regardless to how powerful it is, it is hard to initially understand what it does by just looking at the code. On the contrary the class component lifecycles were very explicit to what it did: componentDidMount for example.

Node JS Express’ Error Middleware

The Node JS Express library allows you to handle errors by passing a callback to the app.use that has four arguments: err, req, res, and next.

Further On Anonymous Functions

The same occurs in other examples. In my experience, JavaScript’s Array.reduce is a common example of the implicitness overhead. If it takes a properly named function as a callback it becomes easier to grasp, else it requires more reading.

58% Is Spent On Comprehension

According to this article we spend most of our time in a codebase trying to understand it. If you agree that explicit code is easier to understand than it should influence how we write code.


Please do not confuse explicit versus implicit with declarative versus imperative.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrei Calazans

Andrei Calazans

Software Engineer - Head Of Vetting At G2i