It’s an important skill for programmers to know when code is “good” or “bad.” That’s the premise of writing good code. After all, if we can’t tell good code from bad, how can we write good code?
So, today we are going to talk about code quality evaluation related issues, I hope that after learning today’s content, code quality evaluation has a clearer, more thorough understanding and understanding.
How do you evaluate code quality?
In fact, the common words “good” and “bad” are a description of code quality. “Good” generally means high code quality, and “bad” generally means low code quality. There are a lot of other ways to describe code quality besides the simple “good” and “bad” descriptions. These descriptions are more semantically rich, professional and detailed.
I collected them and listed them below. These cover almost every common word we hear describing code quality, so take a look.
Flexibility, scalability, maintainability, readability, understandability, easy modification, reuse, testability, modularity, high cohesion and low coupling, high efficiency, high performance…
With so many descriptors, you might ask, what are the words we use to describe the quality of a piece of code?
In fact, it is difficult to evaluate code quality comprehensively by any or all of these terms. Because these words are all from different dimensions. It is just like that we need to evaluate a person from various aspects, such as personality, appearance, ability, wealth and so on. Code quality is also a combination of factors.
What are the most commonly used evaluation criteria?
If you look closely at all of the code quality criteria listed above, you will find that some of the terms are too general and abstract, and tend to describe the whole, such as elegant, good, bad, clean, clear, etc. Some are too detailed and methodologically oriented, such as modularity, high cohesion, low coupling, detailed documentation, and clear layering. Some may not be limited to coding, but may also be related to architectural design, such as scalability, availability, stability, etc.
In order to achieve a focused and focused study, I have selected some of the most commonly used and most important evaluation criteria, including: maintainability, readability, extensibility, flexibility, simplicity (simple, complex), reusability, testability. Now, let’s go through them one by one.
1.Maintainability (maintainability)
First, what is “maintainable” code? What exactly does “maintenance code” involve? When it comes to code development, “maintenance” is nothing more than fixing bugs, modifying old code, adding new code and so on. The so-called”
Code maintainable is the ability to change or add code quickly without breaking the original code design or introducing new bugs. “Code is not maintainable” means that changes or additions to code run a significant risk of introducing new bugs and can take a long time to complete.
The maintainability of code is the result of many factors working together. Good readability, simplicity and scalability of the code will make the code easy to maintain; On the contrary, it makes the code difficult to maintain. More specifically, if the code is cleanly layered, modularized, highly cohesive and low coupled, follows design principles based on interfaces rather than implementation programming, and so on, that might mean that the code is maintainable.
In addition, the maintainability of code also depends on the amount of code in the project, the complexity of the business, the complexity of the technology utilized, the completeness of the documentation, the development level of the team members, and many other factors. So it’s a little harder to analyze whether a code is maintainable or not from a positive perspective. However, we can give a more subjective but more accurate feeling from the side.
If bugs are easy to fix, and changes and additions are easy to make, then we can assume that the code is maintainable to us. On the other hand, if it takes a long time to fix a bug, change a feature, add a feature, we can assume that the code is not maintainable.
2.Readability (readability)
In my opinion, the readability of code should be one of the most important indicators of code quality. When we write code, we should always consider whether the code is easy to read and understand. In addition, the readability of your code greatly affects the maintainability of your code.
Since readability is so important, how do we evaluate the readability of a piece of code?
We need to see if the code conforms to the code specification, if the name makes sense, if the comments are detailed, if the function length is appropriate, if the modules are clearly divided, if the code conforms to high cohesion and low coupling, and so on. You can also sense that, on the positive side, it’s hard to give a list that covers all metrics. This is why readability cannot be quantified. In fact, code review is a great way to test code readability.
If your code can be easily read by your colleagues, your code is readable. If your colleagues read your code and have a lot of questions, your code readability needs to improve.
3. Extensibility
Extensibility is also an important criterion for evaluating code quality. It represents the ability of our code to respond to future changes in requirements. As well as readability, the ease of extension of code largely determines how easy it is to maintain. So what exactly is code extensibility?
The extensibility of the code means that we add new functional code by extension without modifying or slightly modifying the original code. To put it bluntly, the code reserves some extension points, and you can plug the new feature code directly into the extension points, without having to change a lot of the original code to add a feature.
In terms of code extensibility, I’ll cover this in more detail when I talk about the “close to change, open to extension” design principle. Today, we just need to know that code extensibility is a very important criterion for evaluating code quality.
4. Flexibility
Flexibility is also a common term used to describe code quality. For example, we often hear statements like, “The code is very flexible
“. So what does “flexible” mean here? Although many people use this term to describe the quality of code. But actually, flexibility is a rather abstract criterion, and it is difficult to define flexibility. However, when do we say that code is flexible? Here are a few scenarios that I hope will get you thinking about what flexibility is.
When we add a new function code, the original code has already reserved the extension point, we do not need to modify the original code, just add new code on the extension point. At this point, in addition to saying that the code is easy to expand, we can also say that the code is very flexible.
When we want to implement a function, we find that the original code, has been abstracted out a lot of low-level reusable modules, classes and other code, we can use directly. At this point, in addition to saying that the code is easy to reuse, we can also say that the code is very flexible.
When we use a set of interfaces that can be used in a variety of scenarios and meet a variety of needs, we can say that the interface is not only easy to use, but also that the interface is designed or written flexibly.
In the context of the scenario just presented, a piece of code is considered flexible if it is easily extensible, reusable, or easy to use. So, the word flexible has a very broad meaning and can be used in many situations.
5. Simplicity
There’s a very famous design principle that you’ve heard of, and that’s the KISS principle: “Keep It Simple, Stupid.” What this principle says is, keep your code simple. The code is simple and logical, which means easy to read and maintain. When we write code, we tend to put simplicity and clarity first.
However, many inexperienced programmers feel that simple code is untechnical and like to introduce complex design patterns into their projects to demonstrate their skill level. In fact, thinking deep and acting simple, real masters can easily solve the most complex problems in the simplest way. This is one of the essential differences between an experienced programmer and a novice programmer.
On top of that, while we all recognize that code should be as clean as possible, in accordance with the KISS principle, what is clean enough? Not everyone can tell this with great accuracy. Therefore, in later chapters, when we talk about the KISS principle, I will explain to you in detail “why the KISS principle seems very simple and easy to understand, but in fact it is not easy to use” through specific code examples. Today, we won’t go into the details.
6. Reusability
Code reusability can be simply understood as minimizing the need to write duplicate code and reusing existing code. We will refer to “reusability” as a code evaluation criterion in many subsequent chapters.
For example, when we talk about object-oriented features, we talk about inheritance, one of the purposes of polymorphism, is to make code reusable; When we talk about design principles, we’ll talk about the single responsibility principle also has to do with reusability of code; When we talk about refactoring techniques, we’ll talk about decoupling, high cohesion, modularity, and so on to improve code reusability. It can be seen that reusability is also a very important code evaluation criterion, which is the end result of many design principles, ideas, patterns, etc.
In fact, code reusability is closely related to the DRY (Don’t Repeat Yourself) design principle, so I’ll talk more about code reuse in later chapters when we talk about DRY design principles, such as “what programming methods can improve code reusability?”
7. Testability
Compared with the previous six evaluation criteria, code testability is a relatively unmentioned but very important code quality evaluation criteria. The testability of the code is a very accurate reflection of the quality of the code from the side. Poor testability of your code, which makes it harder to write unit tests, is basically a sign that your code is not well designed. The testability of code will be covered in two lectures on refactoring. For now, all you need to know is that testability is important.
How to write high-quality code?
I believe that every engineer wants to write quality code and not keep writing bad code that doesn’t grow and gets teased. So how do you write quality code? We’ve just covered seven of the most common and important metrics for what constitutes high-quality code.
So, to ask how to write high-quality code is to ask how to write code that is easy to maintain, easy to read, easy to extend, flexible, concise, reusable, testable. In order to write high-quality code that meets these evaluation criteria, we need to master some more detailed and practical programming methodology, including object-oriented design ideas, design principles, design patterns, coding specifications, refactoring skills, etc. The ultimate goal of all of these programming methodologies is to write high-quality code.
For example, object-oriented inheritance and polymorphism allow us to write reusable code; Coding specifications allow us to write readable code; Single responsibility in design principles,
DRY
, based on interface rather than implementation, substitution principle, etc., allows us to write reusable, flexible, readable, easy to expand, easy to maintain code; Design patterns allow us to write code that is easily extensible; Continuous refactoring keeps code maintainable, and so on.
1. Search the WEB Guangming Public account on wechat to obtain more activity benefits.
2. Front-end technology exchange and learning, all in the WEB bright top (web.xingruanedu.com)