“When we code, we set high standards and care about the quality of the code we produce. Code reviews are a crucial step of our development process.”
Following the category description, we wanted to understand how you’re using Codacy, and some of the best practices you’ve implemented, depending on the languages you use, so that everyone can get insights on how to better configure Codacy according to their needs. Looking forward to learning more:
Which tools do you normally use and which ones do you disable?
What issue categories are you most interested in? Code style, security, error prone, performance, compatibility, unused code?
Do you prefer to block the merge of pull requests when Codacy finds issues or not?
Which tools do you normally use and which ones do you disable?
Normally we turn off checks around Markdown and the Hadolint since some of the projects we use doesn’t use Docker and etc, so it makes sense to reduce the number of checks.
What issue categories are you most interested in? Code style, security, error prone, performance, compatibility, unused code?
These days I’m being focusing more find duplicated code, since it’s a very old code base we have and the team kept changing over the months, so finding duplicated code and unused code is defo a thing for us
Do you prefer to block the merge of pull requests when Codacy finds issues or not?
Definitely! Codacy is mandatory here and when people come around asking us if we can “skip” Codacy, we tend to make the correct questions about: “why skipping” and if we should raise a technical debt ticket for later - normally it’s a big no to skip, but some devs struggle with the legacy code and we find easier just to raise a technical debt and refactor later.
One thing I really miss is actually being able to add github-bots as a user we can ignore in the checks. :feelsbad:
Sure thing! We have a Github action that automatically deploys our npm package and create a PR to bump our package.json, but because there’s a Codacy check around code quality it blocks the PR from being merged by the team until the check is successful.
Because the bot it’s not a “Codacy user” it doesn’t run the check, so it’s “blocked” until an admin forces merge.
We mostly use pylint (python3) but we don’t usually disable much. We have disabled pylint for python2 but if the tools aren’t triggered then I don’t think they do much harm.
It’s usually a pain when we add a markdown file, but this is because none of our developers are aware of the best practices so we rely on Codacy to tell us about them
Our code is not really a security risk, so these are often the issues that interest us the least. It can be irritating to be told that your random call isn’t sufficiently random for security purposes when you just want to use it for generating values for testing. Although, not irritating enough for us to have turned off this warning.
The ones that really interest us are probably:
error prone
performance
unused code
code style
In that order
We are quite strict with our Codacy issues and block pull requests. Most of our developers are either very junior (interns) or scientists (maths/physics). This means they do not always write the cleanest code. Sometimes this is just due to a lack of knowledge about python shortcuts and Codacy suggests something better, often it’s just unused imports/variables that have been forgotten about. Codacy makes us keep our code clean
Recently we’ve been really strict and increased the checks to include missing doc strings. So no documentation, no merge!
To a certain point yes. At least in python. I imagine it depends on the tools used.
A classic example for us is list comprehensions. They make a big difference to speed in python and new developers are not always aware of this so errors such as pylint’s:
map/filter on lambda could be replaced by comprehension
So far my coding experiece with Codacy not that big but I already see it’s benefits.
Already see many options that will help me in future but at this moment it’s a great tool for several cases:
Debugging - you can check your code every time you made some upgrade, it will find mistakes or pieces of code you should delete now or later (like console.log for example).
Refactoring - already found several ways to refactor my own code lookin on issues from Codacy.
Learning - assuming that Codacy already can provide you an option to check if your code meets general “best practices” you can always learning to make your code look much better.
Mentoring - this option can be very helpful for new developers that can’t find a mentor for themselves. Codacy can check their code like a mentor, find mistakes, give advice.
I think this list is much bigger and I will do my best to update it when I will have even more experience using Codacy.
on Codacy and test suite => no code review.
and perhaps it will solve your issue.
)
