<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Code Style on Daniel Genezini</title><link>https://genezini.com/tags/code-style/</link><description>Recent content in Code Style on Daniel Genezini</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>2022 Daniel Genezini All rights reserved</copyright><lastBuildDate>Tue, 25 Oct 2022 08:00:00 -0300</lastBuildDate><atom:link href="https://genezini.com/tags/code-style/index.xml" rel="self" type="application/rss+xml"/><item><title>Enforcing .NET code style rules at compile time</title><link>https://genezini.com/blog/p/enforcing-.net-code-style-rules-at-compile-time/</link><pubDate>Tue, 25 Oct 2022 08:00:00 -0300</pubDate><guid>https://genezini.com/blog/p/enforcing-.net-code-style-rules-at-compile-time/</guid><description>&lt;img src="https://genezini.com/blog/p/enforcing-.net-code-style-rules-at-compile-time/cover.png" alt="Featured image of post Enforcing .NET code style rules at compile time" /> Static code analysis is a great tool for spotting some kinds of error in your code, for example, not disposing of objects that implement IDisposable. Also, it helps to enforce and validate if the code written is following a defined standard, for example, using PascalCase for class names and camelCase for parameter names.
In this post I'll show how to use Roslyn Analyzers with C# to enforce some standards of code quality and code style on your code, throwing errors at compile time if any rules are not being respected and not allowing the code to be pushed to protected branches of the repository.</description></item><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>