Add a new text
View all texts
hi everyone, my name is Anton, today we’ll talk about the quality of the code
Code quality is a topic that was born with programming, but there is no exact definition and standard for code quality.
Each developer understands quality in his own way, based on experience. Each team for individual projects evaluates the code in its own way.
Clean code increases the viability of the project and lowers the threshold for entry.
When new people appear on the team, they will ask fewer questions. In such a project, it is easier to attract developers due to the low entry threshold.
Our code must be as clean and easy to read as possible.
That is actually the art of programming – to take a complex task and code it in a way that is both correct and human-readable.
A good code style greatly assists in that.
There is such a term as a linear code - it is a code that can be read like a book.
Linear code is read from left to right, from top to bottom, without having to return to the previously written code.
The slide shows an example of linear code
The slide shows an example of non-linear code
No one likes to read a long horizontal line of code. It’s best practice to split them.
The maximum line length should be agreed upon at the team-level. It’s usually 80 or 120 characters.
There are two types of indents:Horizontal indents: 2 or 4 spaces.
A horizontal indentation is made using either 2 or 4 spaces or the horizontal tab symbol (key Tab).
Which one to choose is an old holy war. Spaces are more common nowadays.
Vertical indents: empty lines for splitting code into logical blocks.
Insert an extra newline where it helps to make the code more readable.
There should not be more than nine lines of code without a vertical indentation.
If you are writing several “helper” functions and the code that uses them, there are three ways to organize the functions:
1.Declare the functions above the code that uses them:
2.Code first, then functions
3.Mixed: a function is declared where it’s first used.
That’s because when reading code, we first want to know what it does.
If the code goes first, then it becomes clear from the start.
Then, maybe we won’t need to read the functions at all, especially if their names are descriptive of what they actually do.
What you need to consider in naming.
1.We use CamelCase notation: No transliteration, all method names are in English only
2.Bottom underline for private properties.
3.Constants in capital letters.
4.No one-letter variables.
5. Write clearly, that is, business functionally.
There is no need to make the Check method, which checks something, but what is not clear.
Write the spelling names of the methods.
As we know from the chapter Code structure, comments can be single-line: starting with and multiline
We normally use them to describe how and why the code works.
At first sight, commenting might be obvious, but novices in programming often use them wrongly.
But in good code, the amount of such “explanatory” comments should be minimal.
Seriously, the code should be easy to understand without them.
So, explanatory comments are usually bad. Which comments are good?
Provide a high-level overview of components, how they interact, what’s the control flow in various situations…
In short – the bird’s eye view of the code.
There’s a special language UML to build high-level architecture diagrams explaining the code. Definitely worth studying.
There’s a special syntax JSDoc to document a function: usage, parameters, returned value.
Such comments allow us to understand the purpose of the function and use it the right way without looking in its code.
By the way, many editors like WebStorm can understand them as well and use them to provide autocomplete and some automatic code-checking.
Also, there are tools like JSDoc 3 that can generate HTML-documentation from the comments
Summary: An important sign of a good developer is comments: their presence and even their absence.
Good comments allow us to maintain the code well, come back to it after a delay and use it more effectively.
The first is Commitizen. This is a software utility that I learned about not so long ago -
I looked, felt, liked it. It allows you to standardize message commits, has a nice console interface where you can select features.
If you have commits in the spirit of “fixed a feature” or “fixed a bug”, then it's time to show Commitizen to your colleagues.
Linters is a must-have tool in every project. There are many ready-made configs in linters, but you can write your own rules.
If you have your own rules, then the linter should lint these rules - you will need to write the rules for your Code style.
Useful links on the linter on the slide
Share with your friends: