Our Coding Practices

Ruby Code

Code Should Stand the Test of Time

At Missional Digerati, we strive for quality code. We want our code to stand the test of time and to provide a lasting benefit to the missional community. To assure the quality of the code, we implement several coding practices into our development cycle. Anyone desiring to help out with our projects is required to follow the same coding practices.

Linting

In order to keep code clean and readable, it is important to adopt a standard for writing beautiful code. With a shared standard, we can assure our clients that the code is uniform, clean, and easy to understand. Whenever our code gets pushed to the Git repository, our code is linted, or analyzed for potential syntax errors. If the linting process fails, the code will not be added to the repository, and the developer is responsible for fixing the code syntax. The syntax standard varies between programming languages. Here is a list of standards that we adopt:

Documenting

In order to maintain an understanding of our code and how it works for future development, it is important to correctly document all of our code’s functionality. Using different programming language specific libraries, our code is carefully documented in order to develop a solid working report of the code’s functionality and structure. This allows any developer to assess the purpose of certain functionality and address any concerns in the code. Here is a list of document tools we use based on the programming language:

Licensing

At the heart of Missional Digerati, we want to maintain code that is freely accessible to anyone in the missional community. To insure the free access to our code, we release all of our code under the GNU General Public License (version 3). In the root directory of all our code repositories we place a file titled COPYING which contains the license agreement in it’s entirety. Also, each file in the code repository must contain at the top of the file the following comment block:

/**
 * This file is part of Project Name.
 * 
 * Project Name is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * Project Name is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see 
 * <http://www.gnu.org/licenses/>.
 *
 * @author Author <Author Email>
 * @license http://opensource.org/licenses/gpl-license.php GNU Public License
 * 
 */

This license enables mission agencies to freely use, modify, and distribute our code without any copyright restrictions.

Testing

In order to assure the code performs the way it should, we develop test benchmarks to verify the code base. These benchmarks are crafted based on the specifications provided by our clients. Testing provides assurance in our code development, and provides a mechanism to know when the code breaks. We run these tests everytime we develop new code, or add to existing code. It gives us confidence in our work. The test development varies based on programming language.

Versioning

As code changes, it is important to keep a history of those changes. All of our projects implement the Git versioning control system. Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Most of our code ends up on Github, a social network for storing Git based projects, which provides an effective way to manage the project, and track any issues related to the code.

In order to best manage our Git repositories, we implement a 5 branching strategy for our code base laid out in this document. Ideally, all working code is stored on a develop branch and the actual releases are tagged and stored on the master branch. By implementing this 5 branching strategy, we can help maintain a clean, and well organized Git repository.

We also implement a simple set of rules and requirements that dictates how version numbers are assigned and incremented. We follow the semantic versioning techniques laid out in this document. To maintain the versioning number, we use a Ruby gem called Semver in all of our projects.

Share