SOFTWARE DEVELOPMENT AND QUALITY CODE, METRICS REQUIRED.
"So yes, rest assured, I understand the easy assumption that one can ascertain a codebase’s quality by opening it up and starting to review it. But what does this really tell you? What comes out of this activity?" - Erik Dietrich
Img src:- google
your opinion of the codebase’s quality comes out of this activity which is the deterministic factor for "quality code analysis" as a subset of software development. The strategies required to perform this activity can’t be overemphasized.
CYCLOMATIC COMPLEXITY.
Starting your Code quality evaluation, quantitative measure of the number of "linearly independent paths through the program’s source code should be taking into consideration. The "Cyclomatic Complexity" developed by Thomas J McCabe is actually the bedrock to your quality code detection and Software evaluation metrics. A code with low complexity and well structured algorithm is said to be ready for depolyment (I won’t disagree with this fact but I will rather confess that there are more metrics to be considered while this piece is promising to chew all even down to the nub as you commit and I keeping pushing together). Noting, what is Cyclomatic Complexity?.
"The cyclomatic complexity of a code is the number of linearly independent paths within it. For instance, if the source code contained no control flow statements (conditionals or decision points), the complexity would be 1, since there would be only a single path through the code. If the code had one single-condition IF statement, there would be two paths through the code: one where the IF statement evaluates to TRUE and another one where it evaluates to FALSE, so the complexity would be 2. Two nested single-condition IFs, or one IF with two conditions, would produce a complexity of 3.Mathematically, the cyclomatic complexity of a structured program is defined with reference to the control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second. The complexity M is then defined as
M = E − N + 2P, where
E = the number of edges.
N = the number of nodes.
P = the number of connected components.
Img src:- wikipedia
The same function as above, represented using the alternative formulation, where each exit point is connected back to the entry point. It has 10 edges, 8 nodes, and 1 connected components, which also results in a cyclomatic complexity of 3 using the alternative formulation (10 - 8 + 1 = 3)." -Wikipedia
However, computing codebases cyclomatic complexity and normalizing over the number of methods actually gives a quick overview of the complexity of an average method, which carries critical significance. More tests needed to verify the application’s behavior implies more paths through the code. This is a proper eye-opening to curb testers, developers and other development stakeholders from missing verification scenarios with the risk of deploying unverified contents into production. Take a sip from that Starbucks and let’s get back to work. Scrutinizing our activity in other to get the right metrics for our code evaluation and software development is what I’m still pondering on.
VARIABLE CONVENTION.
"You should name a variable using the same care with which you name a first-born child" -Robert C. Martin
"A programmer is an author and the finisher of a codebase, but they might make the mistake in identifying the audience. The audience of a programmer is other programmers, not computers. If computers were the audience, then you might be writing the code in machine language. Meaningful nomenclature for variables, functions, and classes should be adopted. Indentation, short method, and short statement, where appropriate is the right pill to readability test. Using abbreviations in the variable and method names is uncalled for. Variable name should be in full form so it can be obvious and understandable.
APPARENT FUNCTION
A function should be as short as possible. The ideal length of a method is up to 15 lines. Sometimes it can go longer, but the code should be conceptually clean to understand. If arguments are greater than three, then refactoring function into a class should be the rescue mission. Function or method to a single task should be limited. (Using “and” in a method name, like “validateAndSave" should be avoided. Instead, create two methods, one for validation and another for save). If your method has more than three indentations, then it’s time to refactor in new methods.
One class == one thing. If it is for the user, then all methods must be written entirely for the user experience. Comment only if you need to keep notes on the program’s future or history." -Rakesh Shekhawat
RELIABILITY AND AGILITY
"Reliability and Agility" of the Code won’t be left unchecked in other to determine it quality. Checking the Reliability and Agility contradictions of the code is nothing other than "ensuring simple and clear transition of incident response and instructions (functions)". According to the analysis pattern given by @OverOps in it latest Maturity Model elucidation Reliability and Agility paradox preaches the understanding of "Change Failure Rate (i.e MTTI, MTTR)" and the "Time for Changes Deployment Frequency". Overlooking the code review metrics stated in this piece during a code quality reviewing process would open the development phase not to a bunch of cold coffee drinkers but to what I list as
• Significant Code Level Failures
• Product Roadmaps Derailment
• Increased infrastructure expenses and Immediate loss of service.
The Cyclomatic Complexity and the Reliability Model shows in it advance state as it prioritize issues based on code level data and inform future data collection through real time analysis in classifying code quality. In this guide we have walked through the Quality code detection activity knowing the best is actually "planning out lots of small changes to ensure they (changes) all work together and are all headed in appropriate directions" - Derek D' Alessandro.
©2019, Heritage Samuel Falodun. (Mobile Developer)
