Conventions over the configuration programming pattern

When starting to learn a programming language, for example, C#, Java, Python, or PHP different frameworks and tools come up as a result that person needs to learn as well. There is not much a developer can do only by using programming language by itself, or if they decide to do that, it would take a long time to write things from scratch. Frameworks already have been written to provide many different needed functions and libraries of functions that can be used in the day to day programming to expedite things, and make an application more secure and properly written.

But, enough of this framework talk. One of the things a developer will be hearing a lot of is that this is the conventions over the configuration programming pattern, or that this is configuration-based programming pattern. In this post, I would like to do some more digging into these concepts and what is the difference and why Microsoft technologies and possibly other ones use conventions over the configuration programming pattern.

So the questions to answer are as follows:

What is Conventions-based programming pattern?
What is Configuration-based programming pattern?
What is the conventions over the configuration programming pattern is?

Why use one or the other, if there is such a choice available?

Conventions-based Programming Pattern/ Coding by Convention

Francisco Saez writes an interesting article about Convention over Configuration principles. In this article, the Ruby on Rails framework is presented as a great example of a framework where convention over configuration is highly encouraged, and the whole framework is based on this approach. It uses the convention to guide programmers in the coding work while eliminating a need to make many decisions that are already have been decided upon to be done in a certain way and fought out previously by the framework creators to be the best approach to solving that specific problem.

According to Saez, convention over configuration is a simple concept where the environment in a programming role, such as systems, libraries, language…, is assumed to encompass many logical situations by default, and “rules” of engagement have been set. Typically the assumption and claim are that if a programmer is to follow these conventions, then the immediate result is that more things can be created in a more efficient manner. Time is not spent on making those basic decisions but on actual coding and resolving the programming solution at hand.

Here is a definition of Convention over Configuration from technopedia:

“Convention over configuration is a software development approach geared toward developing programs according to typical programming conventions, versus programmer defined configurations. It enables quick and simple software creation while maintaining base software requirements.”

Convention over configuration is also known as coding by convention.

Techopedia explains Convention over Configuration

“Convention over configuration relies on the development of a program through the use of an underlying language’s native procedures, functions, classes, and variables. This approach reduces or eliminates the need for additional software configuration files, ultimately facilitating and expediting software development, code consistency, and maintenance. However, to follow these conventions, a software developer must be acquainted with the underlying framework.”

Below is a list of benefits and liabilities written by Nicholas Chen:

The Convention over Configuration pattern has the following benefits and liabilities:

+ Allows new developers to learn a system quickly. Once developers understand the naming convention, they can quickly start developing without worrying about writing the configurations to make things work. This gives developers the impression that the framework Works Out of the Box¹⁵with little or no configuration. Frameworks that work out of the box empowers developers to quickly create prototypes for testing. Compare this to frameworks that require multiple configuration files to get the system up and running even for simple tasks. After they have become more familiar with the framework, they can write configurations for the unconventional cases.
+ Promotes uniformity. Developers working on different projects but using the same framework can quickly grasp how different systems work since the same naming conventions are promoted throughout the framework. This helps in maintaining a ubiquitous language³ for the development team.
+ Better dynamism. Changing the name of the class or method in the source code does not require modifying a configuration file. Since the framework does not rely on static configuration files, but rather enforces the naming conventions during runtime, changes made are automatically propagated through the application.

“This is the problem with conventions – they have to be continually resold to each developer. If the developer has not learned the convention or does not agree with it, then the convention will be violated. And one violation can compromise the whole structure.” -Robert C. Martin²”

– Requires familiarity. The naming conventions become part of the implicit knowledge of the framework. Once a set of conventions has been established, it becomes hard to change them. In fact, not following those conventions makes the system harder to use. Naming conventions have to be included in the documentation and followed consistently in code samples to avoid confusion.
– Larger framework. By shifting the responsibility of configuration from the developer, the framework itself has to enforce those conventions; the set of conventions has to be baked into the framework. If there are a large number of conventions that need to be supported, the framework becomes larger. Thus, only enforce clear and practical naming conventions in the framework itself.
– Hard to refactor existing frameworks to adopt a new naming convention. It might not be feasible to use Convention over Configuration when an existing framework has a large group of developers using it. There are currently no automated tools that can upgrade an application to use features in a newer version of the framework. So developers using a version of the framework that used an older convention cannot upgrade easily to a newer convention. The Convention over Configuration pattern is best used during the initial creation of the framework and maintained throughout updates to the framework.

Configuration-based Programming Pattern

Configuration-based programming is when configuration files are used with the programming language to specify different parts of the program what they should do, what other functionality they should include, and certain behavioral settings are specified there as well. For example, Magento Framework uses configuration XML files to specify different modules that can be included in the program. This functionality comes over from the Zend framework that is used in Magento. The stacking order of these modules and other fields or portions of the module itself. Magento is an MVC pattern framework where all of the functionality consists of different modules, and these modules are crafted together to build a web app or web store. Each module has its own configuration file, and at runtime, they all get compiled into a single configuration file that is later used to run the web application on the server. In this case, XML configuration files are used to configure the program look and feel. The order of modules and other configurations are set and controlled through the XML configuration files.

I presume that the configuration-based programming approach will differ from framework to framework. But, the concept will remain the same. Use configuration file in the specific format (XML or JSON) to specify configuration values and controls to different parts of the program.

Conventions over the Configuration Programming

Conventions Programming is the same concept that is called a Conventions over the configuration programming. And we already covered that previously.

Why use one or the other

There are different reasons that are typically presented for the usage case of both approaches. Some frameworks use both in conjunctions. Like MVC pattern with XML configuration files used in the Magento Framework.

I personally find that most of the frameworks use both patterns, the only degree of presence of one over the other varies based on the chosen approach that to be the dominant one.