Stylecop to narzędzie do analizy stylów, które działa na poziomie kodu źródłowego. Istnieje głównie po to, aby zapewnić jeden wspólny styl, którego mogą używać zarządzane projekty, aby zachować spójność w szerszym świecie zarządzanego oprogramowania. Podejmuje decyzje dotyczące stylu przede wszystkim po to, aby uniknąć świętych wojen (w końcu styl jest prawie zawsze z natury subiektywną rzeczą). Nie sądzę, żebym kiedykolwiek spotkał kogoś, kto lubiłby wszystkie zasady StyleCop, ale to jest w porządku . Oznacza to, że StyleCop jest ogólnie dobrym kompromisem pośród szerokiego zestawu istniejących wytycznych dotyczących stylu. (Gdyby reguły stylecop były wysoce konfigurowalne, poza prostym włączaniem / wyłączaniem ich, zniweczyłoby to cały cel narzędzia.)
Z drugiej strony FxCop to narzędzie do analizy statycznej, które działa na poziomie zarządzanego zespołu. Można mu nadawać wskazówki poprzez atrybuty, ponieważ może zobaczyć atrybuty na elementach kodu, np. Wykrywa problemy, które można dostrzec na poziomie „binarnym” (niejako) w przeciwieństwie do poziomu składniowego.
Odpowiadając na twoje pytanie, StyleCop nie zastępuje FxCop, a FxCop nie zastępuje stylecop. Są to dwa różne narzędzia o dwóch różnych celach, które mogą przynieść rzeczywiste korzyści dla twojego kodu.
(AKA, biegam z oboma. :))
Kilka przykładów rzeczy, które można wykryć w porównaniu z innymi, które mogą wykryć:
Naruszenia StyleCop mogą obejmować ostrzeżenia związane z: białymi znakami, formatowaniem, dokumentacją metod publicznych za pośrednictwem komentarzy xml, kolejnością definicji metod w klasie.
Naruszenia FxCop mogą obejmować ostrzeżenia związane z: globalizacją, ścisłym sprzężeniem, cykliczną złożonością, potencjalnymi zerowymi dereferencjami.
Tak, poprzednie odpowiedzi porównujące te dwie odpowiedzi są błędne pod każdym względem. StyleCop i FxCop wykonują dwa bardzo różne zadania i warto zbadać wartość, jaką każdy z nich zapewnia w bazie kodu i dlaczego warto je uruchamiać.
Jedidja
3
Zgadzam się, że nie wszystkie zasady StyleCop są dobre, ale jak mówisz, te, których nie chcesz, można wyłączyć. Używamy StyleCop - po wyłączeniu zwykłych, głupich reguł zapewnia nam dobrą wartość - niskim kosztem ..! Zalecana. (zauważ, że nienawidziliśmy tego na pierwszy rzut oka ..)
stiank81
@ stiank81: Tak, myślę, że na początku wszyscy nienawidzą StyleCop. Jednak po pewnym czasie korzyści naprawdę się utrwalają i okazuje się być bardzo przydatnym narzędziem do utrzymania spójności źródła. :)
Greg D
1
świetna odpowiedź, czego szukałem :)
GibboK
16
stylecop działa na Twoim kodzie źródłowym C #. fxcop sprawdza skompilowany kod z dowolnego języka .net.
Więc jeśli używasz Stylecop, czy FXCop może dodać jakąś wartość?
JL.
Naprawdę lepiej jest korzystać z FxCop.
Andrew Rollings,
Przynajmniej na razie, dopóki nie stanie się bardziej konfigurowalny. :)
Andrew Rollings,
1
Jest mało prawdopodobne, aby stylecop stał się znacznie bardziej konfigurowalny. O wiele ważniejszą funkcją stylecop jest automatyczna korekta naruszeń stylu.
Greg D
używamy Resharpera do automagicznego dostosowania kodu do reguł stylecop. Już samo to sprawia, że jest wart ceny zakupu. Oprócz tego otrzymujesz wszystkie inne korzyści.
Brak zwrotów Brak zwrotów
11
Alternatywą lub dobrym uzupełnieniem FxCop / StyleCop byłoby użycie komercyjnego narzędzia NDepend . Za pomocą tego narzędzia można napisać regułę kodu w zapytaniach LINQ (a mianowicie CQLinq) . Zastrzeżenie: jestem jednym z twórców narzędzia
Domyślnie proponowanych jest ponad 200 reguł kodowych , w tym projekt , architektura , jakość kodu , ewolucję kodu , konwencje nazewnictwa , martwego kodu , wykorzystanie .NET Fx ...
Siła CQLinq w porównaniu z FxCop lub StyleCop polega na tym, że napisanie reguły kodu jest proste i natychmiast uzyskać wyniki. Proponowane są narzędzia do przeglądania dopasowanych elementów kodu. Konkretnie wygląda to tak:
FXCop wykonuje statyczną analizę kodu zarządzanych zestawów kodu. Potraktuj to jako znajdowanie problemów, które spowodują problemy w czasie wykonywania lub wpłyną na to, jak programista uważa, że kod będzie działał (kod nieosiągalny).
StyleCop analizuje strukturę Twojego kodu z punktu widzenia tekstu. Pomyśl o tym jako o problemach, które wpłyną na Twoje środowisko programistyczne i projektowe (formatowanie, konwencje nazewnictwa, dokumentacja)
Oba są BARDZO cennymi narzędziami i powinieneś używać obu, ale skupiają się one na innych problemach.
Odpowiedzi:
Stylecop to narzędzie do analizy stylów, które działa na poziomie kodu źródłowego. Istnieje głównie po to, aby zapewnić jeden wspólny styl, którego mogą używać zarządzane projekty, aby zachować spójność w szerszym świecie zarządzanego oprogramowania. Podejmuje decyzje dotyczące stylu przede wszystkim po to, aby uniknąć świętych wojen (w końcu styl jest prawie zawsze z natury subiektywną rzeczą). Nie sądzę, żebym kiedykolwiek spotkał kogoś, kto lubiłby wszystkie zasady StyleCop, ale to jest w porządku . Oznacza to, że StyleCop jest ogólnie dobrym kompromisem pośród szerokiego zestawu istniejących wytycznych dotyczących stylu. (Gdyby reguły stylecop były wysoce konfigurowalne, poza prostym włączaniem / wyłączaniem ich, zniweczyłoby to cały cel narzędzia.)
Z drugiej strony FxCop to narzędzie do analizy statycznej, które działa na poziomie zarządzanego zespołu. Można mu nadawać wskazówki poprzez atrybuty, ponieważ może zobaczyć atrybuty na elementach kodu, np. Wykrywa problemy, które można dostrzec na poziomie „binarnym” (niejako) w przeciwieństwie do poziomu składniowego.
Odpowiadając na twoje pytanie, StyleCop nie zastępuje FxCop, a FxCop nie zastępuje stylecop. Są to dwa różne narzędzia o dwóch różnych celach, które mogą przynieść rzeczywiste korzyści dla twojego kodu.
(AKA, biegam z oboma. :))
Kilka przykładów rzeczy, które można wykryć w porównaniu z innymi, które mogą wykryć:
Naruszenia StyleCop mogą obejmować ostrzeżenia związane z: białymi znakami, formatowaniem, dokumentacją metod publicznych za pośrednictwem komentarzy xml, kolejnością definicji metod w klasie.
Naruszenia FxCop mogą obejmować ostrzeżenia związane z: globalizacją, ścisłym sprzężeniem, cykliczną złożonością, potencjalnymi zerowymi dereferencjami.
źródło
stylecop działa na Twoim kodzie źródłowym C #. fxcop sprawdza skompilowany kod z dowolnego języka .net.
źródło
Alternatywą lub dobrym uzupełnieniem FxCop / StyleCop byłoby użycie komercyjnego narzędzia NDepend . Za pomocą tego narzędzia można napisać regułę kodu w zapytaniach LINQ (a mianowicie CQLinq) . Zastrzeżenie: jestem jednym z twórców narzędzia
Domyślnie proponowanych jest ponad 200 reguł kodowych , w tym projekt , architektura , jakość kodu , ewolucję kodu , konwencje nazewnictwa , martwego kodu , wykorzystanie .NET Fx ...
CQLinq jest przeznaczony do pisania reguł kodu, które można zweryfikować na żywo w programie Visual Studio lub które można zweryfikować podczas procesu kompilacji i zgłosić w raporcie HTML / javascript .
Siła CQLinq w porównaniu z FxCop lub StyleCop polega na tym, że napisanie reguły kodu jest proste i natychmiast uzyskać wyniki. Proponowane są narzędzia do przeglądania dopasowanych elementów kodu. Konkretnie wygląda to tak:
źródło
FXCop wykonuje statyczną analizę kodu zarządzanych zestawów kodu. Potraktuj to jako znajdowanie problemów, które spowodują problemy w czasie wykonywania lub wpłyną na to, jak programista uważa, że kod będzie działał (kod nieosiągalny).
StyleCop analizuje strukturę Twojego kodu z punktu widzenia tekstu. Pomyśl o tym jako o problemach, które wpłyną na Twoje środowisko programistyczne i projektowe (formatowanie, konwencje nazewnictwa, dokumentacja)
Oba są BARDZO cennymi narzędziami i powinieneś używać obu, ale skupiają się one na innych problemach.
źródło
StyleCop wykonuje analizę kodu źródłowego jest mało konfigurowalna. Tak naprawdę nie robi tego samego, co FxCop, który analizuje skompilowany kod.
Artykuły na Wikipedii na ten temat zawierają dobre podsumowanie różnic:
http://en.wikipedia.org/wiki/StyleCop
http://en.wikipedia.org/wiki/FxCop
źródło