On April 27th, we did a webinar called Don’t drop the ball: Keeping your code up to standards. 

Developers spend around 40% of their time on code maintenance, but they would probably prefer to focus on more exciting things like improving and innovating the product. When teams are creating new projects and repos on a daily basis, it can get pretty tricky to debug the code and maintain it up to standards.

In our webinar, Hélio Rocha, Lead Solutions Engineer at Codacy, talked about:

• What are coding standards, the advantages of using them, and where to start;
• What can go wrong on IT projects – a personal story and lessons learned;
• Best practices and how Codacy can help.

In case you missed the webinar live, don’t worry: you can (re)watch the recording here or below👇

Answering your questions

After the Hélio’s talk, we opened the floor to all the questions the audience might have. You can check the detailed answers on our video recording of the webinar — we even give you the specific time frames! But we’ve summarized the answers for you to read 🤓

What is the product flow for working with monorepo-type projects within Codacy? Is there a way to specify multiple projects per version control repository, or does Codacy recommend treating monorepos with multiple “logical projects” as a single “Codacy project” (00:14:53)

Our approach to monorepos is simple, but it depends on the tools. For example, some tools support having different configurations for different folders, but others don’t. 

A monorepo in JavaScript can inherit the ESLint configuration file, and you can then put it in different folders and apply different rules. So, if you have a Node.js folder and a React folder, you can extend the basic ESLint file and apply different rules for each specific folder. 

On the other hand, if it’s a monorepo in Java, you’ll need to stick with the same rules. But, in Java, you’ll probably want those rules in every folder anyway 😉

How would this work when we have, e.g., Pylint and ESLint rules in the root of the repo, and we want to run linting on a pre-commit hook as well? How can we ensure that we don’t have separate rule sets? (00:16:47)

In this scenario, you’ll have two different quality gates. Pylint and ESLint will apply one in the pre-commit hook, and Codacy will register your regular pull request or merge request pipeline and block it if it’s not up to standards. 

In practice, you have a double-check. Codacy provides the one at the git provider level and prevents the merge if you have the branch protection enabled. As such, you don’t need the pre-commit hook; you still have the analysis after you commit but before merging the PR.

So you should not have pre-commit hooks? There’s nothing against it, as long as it makes sense for your team. However, an approach with a centralized gateway control with a tool like Codacy, where the tool can analyze the code and block the PR if it’s not up to standards, provides valuable feedback for the user.

What strategy would you recommend if you are inheriting old code and all of that code does not conform to coding standards, and there are hundreds (and thousands) of issues to fix (00:19:08)

That’s our day-to-day when we are onboarding new customers. The first results of the analysis can be scary! If you never used a tool like Codacy (or even a small linter), you’ll be surprised with the type and number of issues you see. 

The best strategy is not to stress and then try to enforce your team to fix the issues:

• Give the team time to accommodate the tool and accept the feedback. Your team needs to understand if the feedback is valuable. For example, if you have 60 000 issues, but 30 000 are single quotes versus double quotes, this is a configuration problem. You can fine-tune it and reduce it to 30 000 issues. 
• Define quality gates. But don’t do it in the first couple of weeks because the team is getting used to the tool. First, they’ll learn to get feedback and why they introduced the issue. Then the team will start to understand and get on board with the proper practice. 
• Define a sprint or a couple of sprints to tackle technical debt. Here, assign a team or set of users to clean up the code, starting with the high priority type of issues. So, for example, you can start with the security issues, then the error-prone issues, and then keep digging to reduce your technical debt to the number you defined as a target. 

Thank you to everyone who joined live and those who watched the recording later on! Let’s keep the conversation going in our community.