When you write programs that consist of many lines of code, where the threshold of “many lines” probably begins around fifty lines of code, you should consider organizing your code in ways that will make it easier for you to maintain it in the future. Breaking the code into many functions is a good start, but when you have a lot of functions it can become difficult to manage and remember them. At this point you should consider grouping related functions, and in most programming languages placing the groups of related functions into separate files.
The major benefit is that you, and other developers, can more easily find the code you are looking for when you want to examine or modify it.
You may consider placing all functions you use to generate and send emails into a single file that you name Email.Code. You may move all of your functions for formatting strings into a file name StringFormatting.Code. Organizing your code into separate logically grouped files provides the simple benefit of helping developers find the code to be worked on more quickly. For example, if you are on vacation and I need to fix a bug related to emails in your code, I can find the bug more easily if the email code is in its own file than if all of the program code is in one single large file.
Having many separate files for your code also helps you track changes in the code when you are using a source code control system; which you should be doing. For example, if I made a change several months ago to the Email.Code and I now realize that my change might have broken something, I can use my source code control system to review the changes made to Email.Code more easily than I can use it to review the changes to All.Code.
Business developers often use the technique of object oriented programming to help determine how to organize their code into separate files. The programmer may put all the code related to customers in Customer.Code, and all of the code related to products in Products.Code. Although placing code in separate files is not what object oriented code is really about, it is a natural side effect. Large object oriented applications may use several files for a single “object”. Instead of just a single file for Customers, the code may be broken into several files such as CustomerProperties.Code, CustomerPersistence.Code, and CustomerBusinessRules.Code. Once again the primary reason for multiple files is usually because programmers have learned that many small source code files are easier to develop with than a single large file of code. Another benefit when there are multiple developers may be that each developer focuses on a different area of expertise and one developer focuses on …Persistence.Code files and another developer focuses on …BusinessRules.Code.
An additional approach to organizing code, and I choose the word additional because it could and should be used along with organizing code by object and function, is to group code in different layers of the application architecture together. Many applications today consist of at least three layers:
- a User Interface (UI) layer,
- a business logic layer,
- and a data persistence layer that stores data in files or databases.
It is very beneficial for developers to keep the code in these layers separate because it makes it easier for the developer to make some changes in the future. On such change could be storing data in a different type of database. Another could be replacing the desktop UI with a web page UI.
In object oriented development, developers following the SOLID principles, will implement the “Single Responsibility” principle which leads them to limiting each “class” to doing just one thing, hence the term “Single Responsibility”. Although this does not necessarily dictate that a developer will only have one class per file, that is often the case and thus followers of the “Single Responsibility” pattern are likely to organize code into separate manageable files.
So instead of placing all of your code in a single file like this:
Break the code into separate files like this:
Go to Robert’s Rules of Coders for more.