<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Code Quality on Daniel Genezini</title><link>https://genezini.com/tags/code-quality/</link><description>Recent content in Code Quality on Daniel Genezini</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>2022 Daniel Genezini All rights reserved</copyright><lastBuildDate>Tue, 18 Oct 2022 08:00:00 -0300</lastBuildDate><atom:link href="https://genezini.com/tags/code-quality/index.xml" rel="self" type="application/rss+xml"/><item><title>Defining formatting rules in .NET with EditorConfig</title><link>https://genezini.com/blog/p/defining-formatting-rules-in-.net-with-editorconfig/</link><pubDate>Tue, 18 Oct 2022 08:00:00 -0300</pubDate><guid>https://genezini.com/blog/p/defining-formatting-rules-in-.net-with-editorconfig/</guid><description>&lt;img src="https://genezini.com/blog/p/defining-formatting-rules-in-.net-with-editorconfig/cover.png" alt="Featured image of post Defining formatting rules in .NET with EditorConfig" /> When working with other people and multiple editors/IDEs, it is common to have different editor settings, losing consistency in formatting styles of the code. For example:
Using tabs/spaces and different sizes of indentation, making your code harder to read; Using different encoding between files, causing hard to find bugs at runtime (showing invalid characters) and breaking automated tests. In this post I'll show how to maintain a standard for everyone who works in the code, no matter the editor used, and in a next post I'll show how to enforce these (and other) rules on build and in the continuous integration pipeline.</description></item></channel></rss>