How To Write Clean Code With The Help Of Static Code Analysis

Clean code is what we should all strive for as software engineers. Ask yourself, how many lines of code do you write each day? I will show you how to add static code analysis to your projects to enforce code style and quality guidelines. You'll have your entire team writing clean code in no time.

Join my weekly .NET newsletter:

Read my Blog here:

Subscribe for more:

Chapters
0:00 Editorconfig
1:20 Static code analysis with StyleCop and SonarAnalyzer
3:12 Treating warnings as errors
4:25 Configuring rules severity

[nandkishorsonwale]

Short but sweet information about Clean Code. Thank you.

[danielegiovanetti]

I didn't know about these nuget packages. Thanks Milan for sharing this topic. Writing and mantein clean code is very important and these helps are very important.

[codewithguillaume]

I am currently writing an article on Clean Code and I guess this video will help me! I’ll mention you ;)

[avecesar]

Thank you!!... Your videos has been a great source of knowledge, quality, discovering and goodness.

[MarcusKaseder]

Very good topic! I usually provide the analyzers with its own .editorconfig. It's a bit tricky but it enforces all rules and allows rule updates via a own nuget package.

The nuget provides its own *.props file on build. In that case, developers are not able to suppress errors they don't like because the .editorconfig is overridden on each build 😁 And they can't uninstall the analyzer nuget packages.

Also, it's useful to have different analyzer rules for test projects.

In normal projects its for example not allows to use "magic strings" but in test projects you're allowed to.

That nuget approach is very useful on distributed systems where you usually have a lot small solutions with n projects.

If someone is interested in that solution, just ask 🙂

[kudesnikreal]

This is a good introduction, thank you. I would only try to mention one more thing in such introduction. With .editorconfig it is possible to change the severity level of a rule. But it is also possible to configure the rule's internals, for example for the rule that checks line lengths, it is possible to configure the maximum allowed length, or for the rule that checks nestings - maximum nesting level and so on. A different way is needed to provide such configuration, specific to each nuget package, but usually, it is something similar to an XML file with a predefined name.

[upwgpcm]

Very helpful video, thank you. I am having a problem in my project where I need to disable all analyzers in a specific project directory. I tried to suppress it in the .editorconfig file, but the rest of the rules are more specific, therefore it overwrites the suppression. How could I suppress those directories?

[mesutdemirci]

Thanks for the video , good work milan

[subashbarik]

Thanks for the video , really helpful.

[ramiamara]

Hello, and thank you for this video, i have a question: why in Repository with Update and Add functions you don't use async

[Nashmar]

Hey. Very interesting topic with short helpful introduction into the topic ! Just a question. Are you using both static analyzers (StyleCop SonarAnalyzer) at the same time or they have same features and using just one of them should be enough ?

[michalzemek]

Thanks for the Video, I have one question, How to get Directory.Build.Props to other projects that are in separate GIT repositories ?

[calwayNL]

@Milan I also see CS1591 lines in my .editorconfig. These are Compiler warning that are configurable. Should these also be moved down.

VS just plops those lines somewhere it looks. But some seem to be inside a [*.cs] selector, so they would only apply to *.cs files I think. In my case I think they are now in a [*.{cs, vb}] section so still apply to *.cs but do you know whether this is true, Ie. There position is important if you also have other extension sections in your .editorconfig ?

[angelldark]

interesting, cool, but it's definitely not for a student, thanks, I went to finish my second project.) I fell into the trap when I watched your lessons, and I'm still figuring out the Rusult class. I liked him very much.

[microtech]

Thanks for the video. When you say a solution can contain up to 100 projects or even more. Can you please let us know how we can configure multiple projects on different repositories under the same solution. So the solution should be within the repo having few projects in the same repo but other projects can go in different repo.

[MarusykRoman]

what is your recommendation about configuring PrivateAssets and IncludeAssets?

[sechabamotaung]

This was very cool. Thank you. Question though if for instance you did not want other developers to be able to change the severity of the rule from the nuget package?

Do you have a way?

[ahmadyamout]

Dear can you make like a very small project from a to z using these tools to write a clean code . So for the newbies like me can understand clearly . Thank you

[nigelclark]

Been looking into throwing static code analysis into Git when making pull requests, to assert clean code only gets merged. Been looking at it lightly, but come across random issues. Have you looked into this?

[tryagain]

All good until you mentioned the StyleCop - a real nightmare, same as his predecessor (fxCop). I prefer using SonarQube rules (via SonarLint) for sanity, .editorconfig for enforcing behavior, and the "old" roslyn analyzer.

Also I prefer shipping the .editorconfig file via a NuGet package, with a custom task in the CI pipeline that's validating the the package presence. What's nice about this approach is the fact that you do not depend of a specific path, but you can opt to deliver it via the organization projects, and you can achieve the same with other package managers as well - maven, npm, others.