“See”-ing clean code
To set things in context, software engineering revolves around certain design/structural principles. Which help in managing all in general code-quality of the code base. This is super essential when working in a team. The size of the team is proportional to the need for such a principles.
We have a bunch of design patterns which each take care of “separation of concern” based on what a particular pattern is supposed to do. But we must not forget that the intention starts from a single line of code ⊆ function.
To get some things right straight away:
- Reason why we want to follow these principles is so that each engineer, regardless of the algorithms they implement, should follow some patterns making it easy for readability and understanding purposes(PR reviews become an easier process too 💪).
- This by no means is necessary but such “checks” keeps the standard of the code at par and once the code convention is cemented after couple iterations, such practises make it easier for developers to be onboarded and also development speed enhances as we see similar patterns all around.
There are a couple extensions one can use in VSCode workspace that would help in maintaining such patterns and making it easier to pass those “heartbreaking” pipeline tests before even creating a pull request.
What codemetrics helps with is to break down a function or a class, to a more readable and less cognitively complex structure, by warning us in case we unknowingly add quite a lot of work into one function. This plugin considers certain logic structures as complexity and helps keep a function as compact as possible. Once can say that it forces a developer to think more about the single responsibility principle.
I did mention pipeline actions, what I meant by that, for example, is a CI tool like
Code climate helps set certain rules in a .codeclimate.yml config file, where a team/organisation can configure the codebase to obey certain rules like file-length , cognitive-complexity , function-line , etc. Of course, this needs to be used judicially in certain places like the app source folder and not in migrations, specs and seed scripts. As the goal is the make sure that the source folder is up to the mark and any one(new/experienced) can come in and code a feature while adhering to the configurations.
The objective is to reduce responsibility overload on one code-block and to make it more readable by splitting it. The more readable the code, the better it is at understanding the intention behind it. That helps with scalability, speed and gives a better idea about the data-flow.
This linter extension takes your local .codeclimate.yml file and gives you an idea about why the pipeline tools is failing. They also give the option of a CLI but the extension is much more light-weight.
If you want to get more into the linter specifications and code-climate in general, linked below is a blog which goes deep into it
https://maddevs.io/blog/code-climate-code-analysis-locally-using-vscode-remote-containers/
With this byte sized blog, I conclude that these two extensions have immensely helped my very supportive team and I, to not only better the code quality and readability but to also improve as software engineers. As a byproduct, we are well on our way to have a code-base better suited for more incoming software superheroes.
Until next time, good bye 👋
