If you work in a project with multiple different developers, you might be using EditorConfig to standardize the coding styles and file formats across your team members. EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. Although EditorConfig does a great job here, it only checks for violations locally and only if a developer’s IDE supports it natively or through a plugin. So it could be easily ignored or disabled.

If your OCD is demanding like mine, you cannot accept that! So I created an Azure DevOps Build Step, that checks every incoming Pull Requests for rule violations and lets the build fail if it finds some.

Create a new Pipeline for EditorConf checks

Of course, you could also integrate this into an existing pipeline, but I wanted to keep it separated from my actual build pipeline, because the projects usually build even with style guide violations and I wanted to be able to decide to release anyways.

A new Build Pipeline for Azure DevOps with a single Bash task

Add a new Bash task (runs on all platforms) and paste the following script inline, which downloads the Node.js module eclint and executes it against your src folder. You should change that folder if your code is located somewhere else.

Make sure, to also have the Fail on Standard Error option from the task’s Advanced settings enabled, to make sure the build fails, when the script detects rule violations and writes them to the command line as an error.

If you prefer creating your Build Pipelines with YAML, you can find this build definition as code here.

Checking Pull Requests

If you want to make sure, that all incoming Pull Requests will be checked for EditorConfig violations, just head over to the Triggers tab of your Build Definition and activate Enable pull request validation for it.

Checked Pull Request Validations

GitHub, for example, from now on will trigger the Pipeline for every incoming Pull Request and display the result inside the Pull Request overview. Again, it is useful to have the EditorConfig Check in a separate pipeline, so I can still decide to accept the changes anyway.

Let’s keep our fingers crossed, that the overall code quality in this world becomes a little bit better with that!

Advertisement Block: I will buy myself a pizza every time I make enough money with these ads to do so. So please feed a hungry developer and consider disabling your Ad Blocker.

Robin-Manuel Thiel

At daylight, Robin-Manuel talks about new IT trends and development. But at night he turns into a tinker and developer which sometimes leads to insufficient sleep. He loves cool technologies, cross-platform and everything with a power-plug or IP address.

1 Comment

Enforcing a consistent Coding Style across projects and programming languages – Pumping Code · April 4, 2019 at 22:02

[…] If you are using Azure DevOps as your CI/CD system like I do, check out my other article, which describes how to setup a pipeline in Azure DevOps that checks for Coding Style violations. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.