StyleCop

Nazywanie nieużywanych parametrów _ a StyleCop

Posted on Updated on

Gdy użyjemy _ jako nazwy parametru w metodzie to dostaniemy warning SA1313 (The name of a parameter in C# does not begin with a lower-case letter.). Zdarza mi się taki kod gdy implementuje abstrakcyjną metodę która akurat w danej klasie nie używa jakiegoś parametru. I niestety StyleCop krzyczy.

Rozwiązałem to w ten sposób że ignoruję globalnie tą regułę. Jeśli gdzieś indziej w kodzie ktoś nazwie parametr _table_length to Resharper mi wyłapie ten błąd i zasugeruje poprawę.

Advertisements

[StyleCop] Reguły które wyłączam

Posted on Updated on

… kiedyś opiszę te podstawowe …

A teraz te, z którymi na bieżąco trzeba sobie radzić.

* EF add-migration dodaje trailing whitespace (SA1028) w klasach z kodem migracji. – rozwiazanie niżej w treści posta (Exclude tylko dla danego namespace)

Można wyłączyć reguły per projekt (namespace, class, etc)

Gdy StyleCop zaoferuje nam fixa to możemy dać “Suppress in suppression file” i wtedy zostanie utworzone coś takiego:

// GlobalSuppressions.cs

// This file is used by Code Analysis to maintain SuppressMessage 
// attributes that are applied to this project.
// Project-level suppressions either have no target or are given 
// a specific target and scoped to a namespace, type, member, etc.

using System.Diagnostics.CodeAnalysis;

[assembly: SuppressMessage("StyleCop.CSharp.DocumentationRules", "SA1618:Generic type parameters must be documented", Justification = "<Pending>", Scope = "member", Target = "~M:YourOrganization.Project.Class``2(AutoMapper.IMappingExpression{``0,``1},System.Linq.Expressions.Expression{System.Func{``1,System.Object}})~AutoMapper.IMappingExpression{``0,``1}")]

Dużo przewijania w prawo.

Exclude tylko dla danego namespace

GlobalSuppressions.cs można wrzucić dowolny katalog i wtedy będzie dotyczyło tylko tych z danego i poniżej. Zakładam że namespace’y odpowiadają katalogom.

StyleCop & operator precedence in C#

Posted on Updated on

Przekład niedobrych praktyk które wyłapie StyleCop:

stylecop-conditional-expression-must-declare-precedence

O operator precedence i czy nawiasy są istotne możecie poczytać na:

http://softwareengineering.stackexchange.com/questions/201175/should-i-use-parentheses-in-logical-statements-even-where-not-necessary
– pierwsza i druga odpowiedź warta przeczytania.

Code Review a spacje i inne pierdoły

Posted on Updated on

Chodzi o taką sprawę:

couple random spaces in Code Review

Te ciemno zielone to kilka dodatkowych spacji, które się pojawiło (a nie było ich wcześniej). (Inne to np, dodatkowo zbędna, podwójna linia, brak pustej linii, brak spacji w parametrach lub zbyt duża ich liczba, itp, itd.)

Przypadkowo podczas pracy nad kodem gdzieś się pojawiło kilka spacji za dużo lub za mało. Czy chcielibyśmy przypieprzać się do takich rzeczy na Code Review? – nie bardzo, są ciekawsze rzeczy do kminienia. Jak unikać takich przeszkadzajek.

  • Formatować kod przed commitem, a najlepiej na bieżąco, skrót Ctrl+k, Ctrl+d.
  • Jeśli powyższego nie możemy zrobić, bo ogólnie cały kod jest syfiasty gdy chodzi o wcięcią/formatowani to możemy formatować tylko kod który dodaliśmy. Zaznaczamy kod i ten sam skrót. To akurat robię rzadko.
  • Jeśli już nie możemy (albo nie chcemy) korzystać z automatycznego formatowania to przed pushowaniem do centralnego repozytorium powinniśmy oczyścić commity z takich przeszkadzajem (git rebase interactive)
  • Już naprawdę w ostateczności gdy nic z powyższych nie podziałało to podczas tworzenia pull requesta (obszerny opis o co w tym biega na przykładzie Git/BitBucketa) zobaczmy wszystkie nasze zmiany. Na tym etapie wyłapiemy te pierdoły, na które będzie tracił czas każdy robiący Code Review (a czasem jest to kilka osób, których czas byśmy zmarnowali).

Innym podejściem jest włączeniem do projektu StyleCopa. Dzięki temu wymusimy pewne standardy formatowania, czyli brudną robotę odwali za nas narzędzie.