Geekly Articles each Day
📜 ⬆️ ⬇️

Extending the possibilities of StyleCop


StyleCop - a static analyzer of C # code for matching style - was officially presented to the public in early 2008. By IT standards, this is quite a long time, but for some reason this useful tool has not yet received wide popularity (at least the one it deserves).

Below I will try to analyze the reasons, as well as talk about the new plugin for StyleCop.



Why StyleCop is not very popular?


In addition to developers who are not worried about the coding style at all (hereinafter, only C # language will be discussed), many are frightened by too many errors with the default settings. In my opinion, this is strange - if you care about the coding style, then it is quite natural to check all the settings, deciding for yourself which ones are suitable for adhering to the chosen style.
')
But here the question arises - what is generally understood as a coding style? Is this some kind of uniform style for everyone who writes in C #? Or is each team free to choose it at their discretion?

It seems to me that the very idea of ​​the existence of "uniform" rules is utopian. In general, there are some trends that more and more developers are sticking with over time. However, the language is developing, new constructions are being added (and, therefore, there are more and more ways to use them), and a new wave of discussions and disputes begins.

Nevertheless, Jason Allor - the creator and main ideological inspirer of StyleCop - takes the position that the rules of style should be the same for all. As a result, these rules constitute the very “default settings” that often stop those who would like to use StyleCop.

I would not like to provoke controversy about specific rules - in the end, the styleCop style offered is used by some teams at Microsoft (which means it has a certain “confidence factor”). However, my personal experience shows that the principle of “local style” works most often - i.e. Your style is accepted in a team, in a department, or in the whole organization, and then strictly adhered to.

Here I will note that if your agreements are concluded only in verbal agreements - you can assume that you do not have any agreements. Forced verification (for example, as one of the build steps on a build server) is the only guarantee of compliance. It is here that such tools as StyleCop and show themselves in all its glory.


How can I fix the situation?


Fortunately, StyleCop has a fairly developed system of plug-ins, which allows to significantly expand its functionality (even the set of original rules is technically designed as a separate plug-in). But there are not so many plug-ins to StyleCop. And most of those that can be found are a few scattered rules and look abandoned.

It seems to me that StyleCop would be more useful if it was positioned not as a tool for observing a certain style, but would become a kind of “designer” with which it would be possible to control the observance of the style that your team needs.

StyleCop +


Approximately with such thoughts a year ago I started writing StyleCop + - another plugin for StyleCop. His main idea was and remains unchanged - without imposing specific rules, to provide a wide range of possible checks, allowing you to customize your own style.

The plugin was slowly written in free time and gradually acquired new features. As a result, I decided to share my work and began publishing it on CodePlex. Positive feedback has shown that the work was not done in vain.

Below I would like to briefly describe the main features of StyleCop +. If you already use StyleCop - they may seem interesting to you, but if not - perhaps they were not enough for you, or maybe they will inspire you to write your own extensions.

Advanced naming rules


The history of the emergence of these rules is fairly simple: in our team, we adopted the m_field style for class fields (when the names of private fields begin with different prefixes, in particular, m_ ). StyleCop, on the other hand, only supports this.field- style (when private fields do not have prefixes, but any reference to the fields or methods of the class must be followed by the mandatory this to distinguish fields from, for example, method arguments). Moreover, StyleCop also contains a rule prohibiting the use of underscores in names in general.

Again, I do not dare to say which style is better. But the reality is that different styles already exist (even in .NET BCL, you can observe groups of classes written by different teams at different times - and with different naming styles). And if so - then the tool for style compliance is simply obliged to take into account all this diversity.

Thus, the rules appeared in StyleCop + that allow you to configure almost any object naming system. Functionally, they completely cover the main Naming Rules ( SA13xx ), so the latter can be simply turned off:



The way of configuring these rules is in many ways similar to the similar settings in ReSharper - you have access to a wide range of entities, for each of which you can set your own naming patterns.



For example, the following rule says that the name must either begin with the prefix m_ , followed by the name in camelStyle ( m_rulesMap ), or be fully recorded in PascalStyle ( RulesMap ).



As can be seen from the picture, a number of macros describing the most common capitalization styles can be used in naming templates.

There are also quite a lot of entities, some of which are specifically highlighted separately. For example, someone may not want to rename the standard WinForms event handlers (such as buttonStart_Click ) - which means they may need their own rules, not the ones used for normal methods. Or, someone may specifically call methods that are unit tests (for example, Setting_Null_Throws_Exception ). And the need to have different rules for the names of classes or fields, depending on access modifiers, is completely obvious.

Since capitalization is checked in the names, it is impossible to do without specifying your own list of abbreviations (here they are any combinations of capital letters that should be allowed as a separate word). Also, an option has recently appeared that allows you to ensure that the names of some derived classes end up with the name of the base class (for example, it is common for Attribute , Exception , Stream , etc., but someone may want to add their own exceptions).

More Custom Rules


Like other plugins, StyleCop + contains various additional rules for checking style. There are not many of them yet, but those that exist are quite flexible in configuration (thanks to the active users who suggested many interesting ideas).

A separate interface was created for these rules, which allows you to edit settings more friendly (unlike the traditional interface on the Rules tab, the settings here are not limited to checkboxes with Boolean values ​​and refer to the rule itself).



Extended Original Rules


This is an experimental feature where StyleCop + contains rules that “parasitize” on the original StyleCop rules. For example, the useful rule SA1509: OpeningCurlyBracketsMustNotBePrecededByBlankLine also prohibits "embedded" blocks of code.

// some statements ... { int a; // declaration of local variables required to set value of f1 ... this.f1 = ...; } { int a; // declaration of local variables required to set value of f2 ... this.f2 = ...; }


Its “parasite rule” - SP1509 - contains a setting that allows you to allow such writing. The key point is that this rule does not contain its own code duplicating the original check. Instead, the “parasitic rule” runs the original code from StyleCop, but imposes its own limitations on the result (in the example above, it will not give an error if it is caused by “embedded” code blocks).

Instead of conclusion


If you are not using StyleCop yet, be sure to try it, it should be your must-have tool!
If you do not have enough functionality - write extensions or look for existing ones!

As for StyleCop +, it continues to evolve. Download, use, ask questions on CodePlex. And if it so happens that it is he who will induce at least one developer to start using StyleCop - we can assume that this project has fulfilled its mission by 100%!

Good luck!

____________________

Source: https://habr.com/ru/post/111847/

More articles:


All Articles