CSC/ECE 517 Fall 2013/ch1 1w29 rkld: Difference between revisions
No edit summary |
m (added the benefits section) |
||
| Line 1: | Line 1: | ||
== Convention over configuration == | == Convention over configuration == | ||
Convention over configuration is a software engineering paradigm which aims at reducing the developers efforts by helping him take lesser decisions while still allowing flexibility. | Convention over configuration is a software engineering paradigm which aims at reducing the developers efforts by helping him take lesser decisions while still allowing flexibility. | ||
The idea of convention over configuration is that rather than having to configure several or may be even one large configuration file, one must use conventions to determine how code should work without configuration. Convention over configuration (also known as '''coding by convention''') simply requires to developer to adhere to the conventions specified by the underlying framework . If these are followed in the correct and appropriate manner, the framework interprets the code and delivers output as one would expect from a well defined configuration file. | The idea of convention over configuration is that rather than having to configure several or may be even one large configuration file, one must use conventions to determine how code should work without configuration. Convention over configuration (also known as '''coding by convention''') simply requires to developer to adhere to the conventions specified by the underlying framework . If these are followed in the correct and appropriate manner, the framework interprets the code and delivers output as one would expect from a well defined configuration file. | ||
== Motivation == | == Motivation == | ||
== | == Benefits == | ||
Once developers learn the basic conventions followed by the system, the overall speed with which they will develop the system is increased. They don't need to worry about setting up configurations to get the system to behave as expected. Simple naming paradigms take care of basic routing, associations and application resource usage. | |||
Developers can easily grasp and understand how the modules of an existing system are set up. Making modifications to such modules developed by the team becomes a very fast and clear-cut process. Since the code follows the same basic sets of rules when it comes to naming, the design of the different modules is very straight lined, consistent and easy to understand. | |||
If the naming is done well and adhering to the established conventions, the possibility of manual error when making changes to an existing system is reduced. Uninformed changes to configuration files without a proper understanding of their usage can cause an entire system to halt and throw up errors. | |||
The system understands some things inherently and we don't need to explicitly guide it or tell it to take specific actions for different cases. | |||
== Usage in Ruby on Rails == | == Usage in Ruby on Rails == | ||
== Usage in other framworks == | == Usage in other framworks == | ||
== Drawbacks == | == Drawbacks == | ||
== References == | == References == | ||
Revision as of 23:08, 14 September 2013
Convention over configuration
Convention over configuration is a software engineering paradigm which aims at reducing the developers efforts by helping him take lesser decisions while still allowing flexibility.
The idea of convention over configuration is that rather than having to configure several or may be even one large configuration file, one must use conventions to determine how code should work without configuration. Convention over configuration (also known as coding by convention) simply requires to developer to adhere to the conventions specified by the underlying framework . If these are followed in the correct and appropriate manner, the framework interprets the code and delivers output as one would expect from a well defined configuration file.
Motivation
Benefits
Once developers learn the basic conventions followed by the system, the overall speed with which they will develop the system is increased. They don't need to worry about setting up configurations to get the system to behave as expected. Simple naming paradigms take care of basic routing, associations and application resource usage. Developers can easily grasp and understand how the modules of an existing system are set up. Making modifications to such modules developed by the team becomes a very fast and clear-cut process. Since the code follows the same basic sets of rules when it comes to naming, the design of the different modules is very straight lined, consistent and easy to understand. If the naming is done well and adhering to the established conventions, the possibility of manual error when making changes to an existing system is reduced. Uninformed changes to configuration files without a proper understanding of their usage can cause an entire system to halt and throw up errors. The system understands some things inherently and we don't need to explicitly guide it or tell it to take specific actions for different cases.