Zalecane standardy kodowania .NET / C #? [Zamknięte]

Jakie standardy kodowania są według Ciebie ważne dla projektów .NET / C #? Może to być wszystko od radzenia sobie z nawiasami klamrowymi, odstępami i pedantrią. Albo może to być bardziej podstawowe pytania, takie jak to, co Przestrzenie nazw w .NET Framework, aby unikać, najlepszych praktyk z plików konfiguracyjnych itp

Staraj się unikać tworzenia postów, które są po prostu następstwem innych. Na przykład dobrze byłoby mieć jeden post koncentrujący się na nawiasach klamrowych. Nie potrzebujemy dwóch do obsługi jednego stylu w porównaniu do drugiego. Pomysł nie jest do głosowania dla standardu domowych, lecz ciałem, co należy myślał o przy tworzeniu standardów.

Oto oficjalny Microsoft Guide na standardy kodowania .NET Framework w wersji 4.0.

Jeśli chcesz starszej wersji do 1.1, spróbuj tutaj .

I nie muszą śledzić to do „T”, jak mówią. Jednakże, w razie wątpliwości, jest to najlepsze miejsce do rozpoczęcia się być zgodne z obecnymi ramami .NET, co sprawia, że ​​łatwiej na wszystkich, bez względu na to, czy są one nowe dla danego projektu lub nie.

Może chcesz rzucić okiem na StyleCop . Możesz nawet włączyć go do niektórych systemów kompilacji, aby błędy stylu przerwały kompilację. Ustawienia domyślne są w większości zgodne z tym, co MS sugeruje dla wytycznych (zamieszczone przez innych).

Możesz także zmienić reguły, które są domyślnie dostarczane.

Wskazówki od Microsoft:

• NET - http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
• C # - http://blogs.msdn.com/brada/articles/361363.aspx

Przyjęliśmy to w naszym biurze. Jest napisany przez Lance Hunt i jest dość kompleksowy:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx

Zacznij od FxCop . Poinformuje cię o najlepszych praktyk naruszeń w istniejącym kodzie.

Staram się wybierać wspólny zbiór stylów pochodzących z różnych źródeł. Niektóre z nich nie były wymienione wcześniej:

• dokumentacji z C # kodowania wytyczne - Ostatnia zmiana w 2010 roku
• IDesign C # Standardy kodowania - ostatnia aktualizacja w 2008 roku
• Philips Healthcare - C # Standardy kodowania - Ostatnia zmiana w 2009 roku
• Encodo C # Handbook - ostatnia aktualizacja w 2009 roku

Muszę polecić standardy udostępnione przez SSW (australijskiej firmy doradcze).

Nie tylko kodowanie, ale Project Management etc ... Niezwykle cennym zasobem.

http://www.ssw.com.au/ssw/standards/default.aspx

Metody powinny być krótkie

Większość metod powinna wykorzystywać większość pól w klasie.

Wybierz dobrze swoje imiona.

Np. Przeczytaj książkę Clean Code

Korzystam z następujących aplikacji, aby utrzymać standard kodowania oprócz reguł camelback, nazwy metody itp.

GhostDoc - Dodaje automatycznie wygenerowany komentarz na górze każdej metody. Aplikacja zapewnia dobre wstępne podsumowanie metody. (darmowy)

http://submain.com/products/ghostdoc.aspx

Resharper - analiza i refaktoryzacja kodu http://www.jetbrains.com/resharper/

StyleCop - jako ostatnie sprzątanie przed odprawą w TFS. (darmowy)

http://code.msdn.microsoft.com/sourceanalysis

Nienawidzę ustalonych standardów kodowania, wszystkie zajmują się albo mówieniem ci, żebyś nie popełniał kilku głupich błędów, albo mówieniem ci, jak sformatować kod w ten czy inny sposób. Wszystkie to błahostki.

To znaczy, powiedzą ci, ile spacji należy wstawić między operatorami, jak rozróżniać zmienne, jakie prefiksy w stylu węgierskim używać (np. _ Dla członków), sprzeczne porady (np. Nie możesz nazwać klasy Cxyz, ale musisz zadzwoń interfejs Ixyz), jak układ kodu (umieścić zmienną w górnej klasie lub na dole)

Wszystkie są bezużyteczne na dużym obrazie.

Liczy napisać skuteczne, utrzymaniu i czytelny kod nie jest wymieniony w tych normach.

Na przykład: czy umieścić swoje zmienne w górnej lub dolnej części twojej klasie? Cóż, kogo to obchodzi - co ma znaczenie to, czy ciebie grupować zmienne ze sobą obszaru funkcjonalnego. Że sprawy (będziesz wiedzieć, to jeśli kiedykolwiek widział 20 zmiennych rozrzucone o miejsce).

Mówią, aby umieścić swoje nawiasów klamrowych w niektórych miejscach. Wielka rzecz! Mogę odczytać kodu zarówno w K & R i ANSI stylu bracketing, to nie ma znaczenia. Liczy się to, czy wszystkie klasy Window są w jakiś sposób różnicowane (na przykład z przyrostkiem Form, Dlg itp.), Aby można było zobaczyć, które pliki zawierają kod okna, a które są zwykłymi obiektami.

Rzeczy tak liczy znacznie więcej niż punkty drobnych, które zwykle zawierają normy. Nie wiem, dlaczego tak się rozwinęli, ale często są to po prostu mnóstwo reguł, które przeszkadzają w efektywnym i produktywnym kodowaniu.

Moje standardy starają się bardziej skupiać na organizacji kodu i plików. Mamy pewne standardy, które odnoszą się do miejsca, w którym pliki zostaną znalezione. Na przykład, dla osób niebędących deweloperami, mogą spojrzeć na jeden z naszych projektów i natychmiast wybrać potrzebne pliki dokumentacji. Podobnie staramy się ułożyć kod projektu w sposób podobny do innych projektów jako praktyczny (uwaga: jako praktyczny, a nie w mocno zakazany sposób, który może być nieodpowiedni przez cały czas) i zasadniczo staramy się opracować wytyczne dotyczące standardów, które można modyfikować w razie potrzeby.

W skrócie - są tam, aby pomóc nam pracować razem, a nie jako zbiór restrykcyjnych zasad, które zawsze muszą być przestrzegane.

Ostrzeżenie: pragmatyzm poniżej - pytanie to wydaje się być sformułowane w celu wywołania debaty na temat „właściwego” stylu kędzierzawego klamry itp. Nie marnuję czasu na te bzdury.

1. Zainstaluj ReSharper , pozostaw domyślne, rób co mówi.

2. Zysk - wszyscy w twoim zespole będą mieli ten sam styl, który będzie cholernie zbliżony do wytycznych Microsoft, tylko odbiegając od kilku punktów, w których standardy Resharper odzwierciedlają to, co jest rzeczywiście powszechnie stosowane w branży i są (prawdopodobnie) ulepszeniami.

Im mniej czasu twój zespół spędza na tworzeniu i odwoływaniu się do jakiegoś ogromnego dokumentu lub książki, czy też kłótni na temat curly bracesinnych nieczystości, tym więcej kodowania zostanie zrobione. ReSharper będzie wymuszał nazywanie i styl podczas pisania. Gotowy. End-of-debaty. Nic się spierać. Iść dalej.

To powiedziawszy, przeczytanie klasycznego Code Complete , pomoże im zrozumieć uzasadnienie stojące za standardami kodowania i zaoferuje wiele wspaniałych wskazówek na temat skutecznego przekazywania znaczenia za pomocą kodu - czego nie może zrobić dokument standardu ani program inspekcji.

Jeśli chcesz zwiększyć możliwości resharpera , dodaj StyleCop za pomocą wtyczki StyleCop for ReSharper. Jak wspomniano, będzie kilka drobnych konfliktów między wytycznymi MS a domyślnymi ustawieniami ReSharper. Po prostu poszedłbym na te z ReSharper. Ale niezależnie od tego, którą stronę weźmiesz, zapisz wyniki w pliku konfiguracyjnym ReSharper, udostępnij go zespołowi i gotowe.

(Nie, nie jestem płatnym klientem ReSharper, jestem tylko zadowolonym klientem. Oprócz wielu innych funkcji, obsługuje podstawowe problemy ze stylem bardziej opłacalnie niż jakikolwiek standardowy dokument lub system recenzji kodu - pozostawiając siłę roboczą na rzeczy, które mają znaczenie .)