On April 3rd, we did a webinar called Compliance Matters: Keeping your coding standards high across teams and projects. Our Product Manager André Pires’ talk covered:

• Deeper insights into compliance and the importance of coding standards;
• How to improve your coding standards across teams and projects;
• How Codacy Quality is improving to provide teams with better tools for enforcing rigorous industry standards.

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

A live talk on coding standards

You can check the detailed talk on our video recording – we even give you the specific time frames! But we’ve summarized the topics for you to read 🤓

Multiple Organization Coding Standards (00:03:17)

Before, you could only create one organization coding standard at Codacy Quality. Now, the organization coding standards are more flexible, allowing you to create up to 10 standards. 

Some developers focus more on setting up the issues they want to track. These teams are more focused on patterns they want to avoid going live or getting added to their code base.

A popular use case would be to have coding standards organized by teams. So you can have different coding standards for front-end, back-end, full-stack, or infrastructure. You’ll have different setups for each team, where you want different tools and then fine-tune them to your reality. These multiple coding standards setups are reusable per repository in a fast and effortless way.

In a nutshell, with the current release of the Organization coding standards, you can:

• Create multiple coding standards, either from scratch or from a previously set up repository. In this last scenario, Codacy Quality will help you pre-select the languages, tools, and patterns defined in the repository’s code patterns page.
• Edit the standards you previously created, in case you need to change languages, tools, patterns, and repositories that follow the coding standard. It can also be a change as simple as modifying the name of the standard. 
• Make a coding standard as default, so that new repositories in your organization can automatically follow the default coding standard without any extra configuration.
• Delete coding standards that are no longer applicable or useful for your team.

Coding Standards and Compliance (00:06:38)

There are companies or environments where you’re mostly focused on compliance. In those cases, you want to set up ground rules for all your teams and define the baseline expectation for your code.  You want to ensure this on the Pull Request level.

For example, you can select severity or security as a must for all the tools and programming languages that you use in your daily work.

Your questions, the stars of the show

After a short introduction to the improved Organization coding standards feature, we opened the floor for all the questions the audience might have. You can check the detailed answers on our webinar video recording.

What’s the difference between one of these [coding standards] and an on-build linter? Besides the PR checking (00:12:56)

With coding standards, you can set up tools and linters configurations once and then leverage that configuration for all the repositories you want. It’s more efficient because it’s mostly a centralized setup you can apply to the whole organization.

How do I convince my manager and team to start using coding standards? They don’t really see the benefits (00:15:57)

One of the benefits is that if you have tool checks or setups that you actually invested time to configure, you can leverage all of those changes into all of the other repositories that share the same stack.

In terms of compliance, having coding standards can make your team feel safe. They work as a safety net and quality assurance, making developers more comfortable in their daily work.

However, it always depends on the teams, the business culture, how you work, and your expectations. There is a diverse developers’ community. You must consider your organization’s reality: how you deploy code, how often, how locked your releases are, or if it’s daily CI/CD.

Can you share coding standards across organizations? (I have 2 organizations because we use GitHub and Bitbucket) (00:16:45)

Currently, there is no easy way to share coding standards across organizations. However, you can reuse the configuration file, which covers this use case.

Can you give another example of using coding standards? (00:18:30)

Another example is compliance for the whole organization. First, we can select all of our programming and markup languages. Then, we choose the tools and patterns with a critical severity level and also everything in the security category.

If you are focused on code style and performance, you can select the patterns with those categories. That way, you make these categories a high priority for your team. After this configuration, you can leverage it and quickly apply it to all your repositories.

Is it possible to change the severity for a specific pattern? (00:23:55)

Currently, changing the severity of a specific pattern is not possible.

Coding standards are a tool to leverage and reuse configurations, and the best trade-off is to have the most generic configuration possible and then do some fine-tuning. The fine-tuning might be by repository, by team, or by other criteria.

How many coding standards can we create? (00:24:59)

So far, you can create up to 10 coding standards. We’ve limited this to 10 because it’s a number that should give you enough flexibility to address multiple use cases, stacks, and teams.

Nevertheless, we would love to have your feedback! We would love to talk with you and understand your use cases if you think differently.

Who should define the coding standards? (00:28:14)

We currently limit the coding standards permissions to account managers or owners. 

The organizational coding standards are a wide code pattern setup you can apply to the whole organization. As such, you must have the proper permissions for all the different repositories.

How does Codacy analyze the code in the repositories? (00:29:00)

The main use case is when a repository is tracked on Codacy Quality. When a new commit is being pulled to the Git provider, that will trigger the analysis on our side, and we will publish the status on the Git provider.

There are some different use cases where the analysis is triggered by developers on client-side tools. We don’t natively run these tools in Codacy Quality, but you can set the repositories to control its analysis lifecycle better and trigger the analysis yourself.

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