Welcome to another installment of the “CodeIt.RightRules Explained” series. If the previous sentence doesn’t mean anything to you, don’t despair?here’s a quick recap.
CodeIt.Right?is one of the SubMain’s offerings. You can think of it as an automated code review tool, which puts it into the category of?static code analyzers. CodeIt.Right checks your source code against a set of rules, which could be the default set or ones customized by you.
In this ongoing series, we focus on the standard, pre-packaged sets for obvious reasons: those are the ones that will apply to everyone. In each installment?of the series, we explain three CodeIt.Right rules so that you know why you should or shouldn’t deactivate the rule when using CodeIt.Right.
Speaking of which, we tend to start these posts with the following sentences:
- Never implement a suggested fix without knowing what makes it a fix.
- Never ignore a suggested fix without understanding what makes it a fix.
Basically, you can condense these two rules into: ?Always understand a suggested fix.? But we prefer to present them as two separate rules to emphasize the choice you have in front of you: ignore the warning or implement a fix. If you decide to ignore the warning, do it only when you understand the implications. If you go for the fix, make sure you know what you’re doing and why implementing the fix benefits your code.
With that out of the way, let’s get to today’s rules.
Do Not Use the “Base” Prefix Unless Local Implementation Exists
Today’s first rule falls into the “usage” category. The rule urges us not to prefix calls with the “base” prefix (“MyBase” in Visual Basic) unless it’s necessary. And when is it necessary? Here’s a quick example.
The Problem
Consider the following ConsoleWriter class:
public class ConsoleWriter
{
public void WriteToTheConsole(string message)
{
Console.WriteLine(message);
}
}
Then, consider the ConsoleAndFileWriter class, which inherits from the first one:
public class ConsoleAndFileWriter : ConsoleWriter
{
public void WriteToConsoleAndFile(string message, string filePath)
{
base.WriteToTheConsole(message);
System.IO.File.WriteAllText(filePath, message);
}
}
The “base” prefix before “WriteToTheConsole” isn’t necessary. The base method doesn’t contain the virtual modifier, which means the author of ConsoleWriter never intended for anyone to overwrite the method. All of that means that there’s no ambiguity at all to be solved, which renders the base prefix unnecessary in this case.
The Correct Implementation
Here’s the complete, corrected version of the code:
public class ConsoleWriter
{
public void WriteToTheConsole(string message)
{
Console.WriteLine(message);
}
}
public class ConsoleAndFileWriter : ConsoleWriter
{
public void WriteToConsoleAndFile(string message, string filePath)
{
WriteToTheConsole(message);
System.IO.File.WriteAllText(filePath, message);
}
}
Before we wrap up this topic, let me just say for the record that we don’t recommend such a design as seen in this example. For a problem like this, it’d be better to employ composition instead of inheritance. Which brings us to the next rule…
Avoid Excessive Inheritance
The second rule in today’s post falls into the “maintainability” category. The name of the rule is pretty self-explanatory, but we’re going to go into a bit more detail regardless. First, we have to understand how much inheritance is excessive, and then we need to understand why excessive inheritance would be a problem.
What Is Excessive Inheritance?
It all comes down to a metric called “depth of inheritance.” This metric is a number that indicates the number of levels in the inheritance tree, from the leaves to the root. The rule is violated when the depth of inheritance goes higher than the?MaxInheritanceLevel variable. By default, the value of this variable is 5, but you can customize it to better fit your needs.
Now, why would excessive inheritance be an issue to start with? It all comes down to the readability and maintainability of the code. An inheritance hierarchy that is too deep can make it harder for developers to understand the code. Methods and fields can be defined and redefined in many different places. Think about the many options a developer has to redefine a method: overloading,?overriding, hiding.?A very deep inheritance hierarchy makes it difficult to understand the effects the code will produce once you run it.
Is Inheritance Intrinsically Evil?
It’s interesting to note that many developers nowadays?frown upon the very concept of inheritance. The Design Patterns book, released in 1994, features the phrase, “Favor composition instead of inheritance.” It seems that some people nowadays have taken that sentiment to the extreme and avoid inheritances in all cases. There’s nothing wrong with that, by the way. Some languages don’t even have inheritance as a feature and they seem to be doing just fine.
But if you choose to use inheritance, then use it correctly: avoiding deep hierarchies and following other best practices, such as sealing any class from which you don’t intend people to inherit.
Identifiers Should Be Spelled Correctly
To wrap up today’s post, let’s explore a rule from the “spelling” category: “Identifiers should be spelled correctly.” As with most CodeIt.Right’s rules, its name is self-explanatory, so let’s focus on what I’m sure some (or even most of you) are thinking. Why does such a rule even exist? Does it make a difference if a variable’s spelling is a bit off?
For starters, the topic of spell check in programming is not new to this blog. I’ll draw from both of those above to make this argument: yes, spell check is extremely valuable.
Remember: Not All Programmers Speak English
Not every developer is a native speaker of English. I’m not, for instance, and I’ve been working as a developer for a good long while. Our industry is global. Every year, many programmers from all continents join the rankings of active, professional software developers. English is not an easy language to learn; I can speak from experience. Any help is welcome, especially automated help.
The spell check rule can also discourage some bad practices, such as the usage of unpronounceable names, Hungarian notation, or unknown acronyms.
Of course, the question remains . . . this rule defaults to English as the spell check language. Many programmers in non-English-speaking countries choose to write code in their own native languages. What do you do then?
I’d say it depends on the number of non-English words. If there are few of them (i.e., the developers write mostly in English but choose to keep some terms in their native languages), then you should add those words to the CodeIt.Right’s customer dictionary.
If, on the other hand, they’re writing primarily in their native languages, then the best course of action would be to deactivate the rule. And there would be nothing wrong about that. Remember: “never ignore a suggested fix without understanding what makes it a fix.” If you understand what makes a given rule important, understand the consequences of ignoring it, and have a reason that makes sticking to the rule impossible or impractical, go?ahead and deactivate it. And the “foreign developers writing code in their own languages” scenario definitely checks those three boxes.
Now It’s Back to You
In today?s post, we covered rules falling into the usage, maintainability, and spelling categories, respectively. The rules come from diverse categories, but somehow they fit into one coherent theme: keeping the code as clean, easy to understand, and easy to maintain as possible. In short, that’s pretty much what CodeIt.Right does for your code anyway. Why not download it and give it a try today?
Tune in next time and we’ll have three more CodeIt.Right rules from three different categories waiting for you so you can learn about them, put them into practice, and make your application healthier?and your developers happier. Isn’t that nice? See you next time!
Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.
