variable.less is the first files to be imported in the entry point of Bootstrap 3 LESS. It declare all variables.

This design of variable.less against the rule of thumb that variable should be declare on use. But after considering the design principle of Bootstrap 3, variables.less is a good design. Let’s discuss why this design is bad at the first glance.

Cons of centralize all variable’s declaration

Imagine you are working on a new component, every time you need a new variable, you have to go back variables.less to add a new one. When you forget the value of a variable, you also have to go back variable.less to check the value. Lots of context switching during development.

Pros of declare on use

Declare variable on use can benefit from scope and context. Suppose I am working on navigation bar and I have nav-bar.less. To declare the width of navigation bar, @width may be clear enough to be a variable’s name. Because we are in the context of navigation bar.

If we put all variables in variable.less, we have to use @nav-bar-width. In nav-bar.less, we will see the nav-bar prefix repeat and repeat again. It is redundant and annoying. Why bootstrap 3 design in this way?

Nature of Bootstrap 3

Bootstrap is a open source project. In the documentation, it gives guideline on the source code and encourage user to reuse the mixins. Users are encouraged configure, modify and compile Bootstrap 3 from source code.

variables.less help new users to configure Bootstrap 3 easily

Declare on use make use of context, and it becomes context dependent. But a new user don’t have any context. They need to go through the whole file to find out the declaration variable and what to change. It also increase the maintenance cost when the MOD spread in different part of the source code.

The variables.less does it part to help new users. They can go through variables.less, figure out what can be configure. They can go deep into the implementation when they found something interesting. Users only need to change and maintain variables.less.

Insight - Team project vs Open source project

In a team project, the team does not change frequently. Every member have their own responsibility. Members may have to maintain set of codes in some directories. They try to prevent code conflict by reducing the number of file shared. When a member need to use the code maintained by others, they can get the context quickly by asking the person in charge. This file structure and workflow makes the team work efficiently.

But for a open source project, contributors come and go. The communication cost is high. New users tend to read to code instead of finding someone to ask. Users have to maintain the whole project by themselves. Complex file structure for division of responsibility is not needed. Gathering all configuration makes the structure simpler and easier to maintain.