Czy są jakieś sugestie dotyczące opracowania dokumentu standardów kodowania C # / najlepszych praktyk? [Zamknięte]

Jestem niedawnym absolwentem AI (około 2 lata), pracując przy skromnej operacji. Spadło mi (przede wszystkim dlatego, że jestem pierwszym „adoptującym” w dziale), aby stworzyć podstawowy (czytaj przydatny?) Dokument standardów kodowania C #.

Myślę, że powinienem wyjaśnić, że jestem prawdopodobnie najmłodszym inżynierem oprogramowania, ale nie mogę się doczekać tego zadania, ponieważ mam nadzieję, że faktycznie będę w stanie wyprodukować coś w połowie użytecznego. Przeprowadziłem dość obszerne przeszukanie Internetu i przeczytałem artykuły o tym, co powinien / nie powinien zawierać dokument standardów kodowania. Wydaje się, że to dobre miejsce, aby poprosić o kilka sugestii.

Zdaję sobie sprawę, że potencjalnie otwieram drzwi do całego świata niezgody na temat „najlepszego sposobu robienia rzeczy”. Rozumiem i szanuję niezaprzeczalny fakt, że każdy programista ma preferowaną metodę rozwiązywania każdego indywidualnego zadania, w wyniku czego nie chcę pisać niczego tak drakońskiego zakazu, aby stłumić osobisty talent, ale spróbować uzyskać ogólną metodologię i zgodzić się standardy (np. konwencje nazewnictwa), aby uczynić kod bardziej czytelnym.

A więc oto… jakieś sugestie? W ogóle coś?

Zaczynamy od

• Wytyczne Microsoft .NET: http://msdn.microsoft.com/en-us/library/ms229042.aspx (łącze zaktualizowane do .NET 4.5)
• Wytyczne firmy Microsoft dotyczące języka C #: http://blogs.msdn.com/brada/articles/361363.aspx .

a następnie udokumentuj różnice i dodatki do tej linii bazowej.

IDesign ma dokument standardów kodowania C #, który jest powszechnie używany. Zobacz także wytyczne dotyczące projektowania ram, wyd . 2 .

Jak na ironię, ustalenie rzeczywistych standardów będzie prawdopodobnie łatwą częścią.

Moją pierwszą sugestią byłoby uzyskanie sugestii od innych inżynierów na temat tego, co ich zdaniem powinno być uwzględnione i jakie wytyczne uważają za ważne. Egzekwowanie wszelkiego rodzaju wytycznych wymaga pewnego zaangażowania ludzi. Jeśli nagle upuścisz na nich dokument, który określa, jak pisać kod, napotkasz opór, niezależnie od tego, czy jesteś młodszym, czy najstarszym facetem.

Po przygotowaniu zestawu propozycji wyślij je do zespołu w celu uzyskania opinii i przeglądu. Ponownie, zachęć ludzi, aby wszyscy w nich uwierzyli.

Mogą już istnieć nieformalne praktyki kodowania, które zostały przyjęte (np. Prefiksowanie zmiennych składowych, nazwy funkcji z liter wielbłądów). Jeśli tak jest i większość kodu jest z nim zgodna, wówczas sformalizowanie jego użycia będzie opłacalne. Przyjęcie innego standardu przyniesie więcej smutku, niż jest to warte, nawet jeśli jest to ogólnie zalecane.

Warto również rozważyć refaktoryzację istniejącego kodu, aby spełniał nowe standardy kodowania. Może się to wydawać stratą czasu, ale posiadanie kodu, który nie spełnia standardów, może przynieść skutki odwrotne do zamierzonych, ponieważ będziesz mieć mieszankę różnych stylów. Stawia to również ludzi przed dylematem, czy kod w danym module powinien być zgodny z nowym standardem, czy też zgodny z istniejącym stylem kodu.

Zawsze korzystałem z pliku PDF Juval Lowy jako odniesienia podczas wewnętrznego tworzenia standardów kodowania / najlepszych praktyk. Jest to bardzo zbliżone do FxCop / Source Analysis , które jest kolejnym nieocenionym narzędziem zapewniającym, że standard jest przestrzegany. Pomiędzy tymi narzędziami i referencjami powinieneś być w stanie wymyślić fajny standard, którego wszyscy twoi programiści nie będą mieli nic przeciwko temu i będą w stanie je egzekwować.

Inne plakaty wskazywały na punkt odniesienia, wszystko, co chciałbym dodać, to uczynić twój dokument krótkim, słodkim i na temat, używając dużej dawki Strunk i White, aby odróżnić "must have" od "byłoby miło, gdybyś ”.

Problem z kodowaniem dokumentów standardów polega na tym, że nikt tak naprawdę nie czyta ich tak, jak powinien, a kiedy je czyta, nie przestrzega ich. Prawdopodobieństwo przeczytania i przestrzegania takiego dokumentu zmienia się odwrotnie w zależności od jego długości.

Zgadzam się, że FxCop to dobre narzędzie, ale zbyt duża jego część może odebrać całą radość z programowania, więc bądź ostrożny.

Nigdy nie pisz własnych standardów kodowania, używaj standardów MS (lub Sun lub ... odpowiednio do twojego języka). Wskazówka jest w słowie standard, świat byłby znacznie łatwiejszy do kodowania, gdyby żadna organizacja nie zdecydowała się napisać własnego. Kto naprawdę myśli, że uczenie się nowego zestawu „standardów” za każdym razem, gdy zmieniasz zespół / projekty / role, to dobre wykorzystanie czyjegoś czasu. Jedyne, co powinieneś zrobić, to podsumować punkty krytyczne, ale odradzałbym robienie nawet tego, ponieważ to, co jest krytyczne, różni się w zależności od osoby. Dwie inne kwestie, które chciałbym poruszyć na temat standardów kodowania

1. Zbliżenie jest wystarczająco dobre - zmiana kodu w celu przestrzegania standardów kodowania co do litery jest stratą czasu, o ile kod jest wystarczająco blisko.
2. Jeśli zmieniasz kod, którego nie napisałeś, postępuj zgodnie z „lokalnymi standardami kodowania”, tj. Spraw, aby nowy kod wyglądał jak kod otaczający.

Te dwa punkty są rzeczywistością, zgodnie z moim życzeniem, aby każdy napisał kod, który wyglądałby tak samo.

Poniższa dokumentacja okazała się bardzo pomocna i zwięzła. Pochodzi ze strony idesign.net, a jej autorem jest Juval Lowy

Standard kodowania C #

Uwaga: powyższy link jest teraz martwy. Aby otrzymać plik .zip, musisz podać im swój adres e-mail (ale nie będą go używać w celach marketingowych ... szczerze) Spróbuj tutaj

Właśnie zacząłem od miejsca, w którym standardy kodowania nakazują użycie m_ dla zmiennych składowych, p_ dla parametrów i przedrostków dla typów, takich jak „str” dla łańcuchów. Więc możesz mieć coś takiego w treści metody:

m_strName = p_strName;

Okropny. Naprawdę okropne.

Dodałbym do listy Code Complete 2 (wiem, że Jeff jest tu trochę fanem) ... Jeśli jesteś młodszym programistą, książka przydaje się, aby ustawić swój umysł w sposób, który stworzy podstawy dla najlepszych istnieją praktyki pisania kodu i tworzenia oprogramowania.

Muszę powiedzieć, że doszedłem do tego trochę późno w swojej karierze, ale to w dużej mierze decyduje o tym, jak myślę o kodowaniu i tworzeniu frameworków w moim życiu zawodowym.

Warto sprawdzić;)

Zasady Microsoftu są doskonałym punktem wyjścia. Możesz je egzekwować za pomocą FxCop.

Kusiło mnie, aby wprowadzić standard Microsoft StyleCop. Można to wymusić w czasie kompilacji. ale jeśli masz starszy kod, po prostu wymuś użycie StyleCop na nowym kodzie.

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

Ostatecznie będzie miał opcję refaktoryzacji do czyszczenia kodu.

http://blogs.msdn.com/sourceanalysis/

Osobiście podoba mi się ten, który stworzył IDesign . Ale nie dlatego publikuję ...

Najtrudniejsze w mojej firmie było uwzględnienie wszystkich języków. Wiem, że moja firma nie jest w tym sama. Używamy C #, C, assemblera (tworzymy urządzenia), SQL, XAML itp. Chociaż będą pewne podobieństwa w standardach, to każdy z nich jest zwykle obsługiwany inaczej.

Uważam również, że wyższy poziom standardów ma większy wpływ na jakość produktu końcowego. Na przykład: jak i kiedy używać komentarzy, kiedy wyjątki są obowiązkowe (np. Zdarzenia inicjowane przez użytkownika), czy (lub kiedy) używać wyjątków, a kiedy zwracanych wartości, jaki jest obiektywny sposób określania, jaki powinien być kod kontrolera, a jaki kod prezentacji, itp. Nie zrozumcie mnie źle, potrzebne są również standardy niskiego poziomu (formatowanie jest ważne dla czytelności!). Mam po prostu tendencję do ogólnej struktury.

Kolejnym elementem, o którym należy pamiętać, jest wpisowe i egzekwowanie. Standardy kodowania są świetne. Ale jeśli nikt się z nimi nie zgadza i (prawdopodobnie co ważniejsze) nikt ich nie egzekwuje, to wszystko na nic.

Kiedy pisałem zarówno ten opublikowany dla Philips Medical Systems, jak i ten na http://csharpguidelines.codeplex.com, mogę być nieco stronniczy, ale mam ponad 10 lat na pisanie, utrzymywanie i promowanie standardów kodowania. Próbowałem napisać ten CodePlex z myślą o różnicach zdań i większość wprowadzenia poświęciłem na to, jak sobie z tym poradzić w Twojej organizacji. Przeczytaj go i przekaż mi swoją opinię .....

Zasady SSW

Zawiera niektóre standardy C # + o wiele więcej ... głównie przeznaczone dla programistów Microsoft

Najprawdopodobniej jesteś skonfigurowany do niepowodzenia. Witamy w branży.

Nie zgadzam się - dopóki on tworzy dokument, najgorsze, co może się zdarzyć, to to, że wszyscy o nim zapomną.

Jeśli inne osoby mają problemy z zawartością, możesz poprosić ich o zaktualizowanie jej, aby pokazać, co wolą. W ten sposób nie masz nic do roboty, a inni mają obowiązek uzasadnić swoje zmiany.

Niedawno znalazłem Podręcznik programu Encodo C # , który zawiera pomysły z wielu innych źródeł (IDesign, Philips, MSDN).

Innym źródłem mogą być Wytyczne dotyczące programowania w języku Professional C # / VB .NET .

Jestem wielkim fanem książki Francesco Baleny „ Praktyczne wskazówki i najlepsze praktyki dla programistów VB i C # ”.

Jest bardzo szczegółowy i obejmuje wszystkie istotne tematy. Nie tylko podaje regułę, ale także wyjaśnia powód reguły, a nawet zapewnia anty-regułę, w której mogą istnieć dwie przeciwstawne najlepsze praktyki. Jedynym minusem jest to, że został napisany dla programistów .NET 1.1.

Cały nasz standard kodowania brzmi mniej więcej „Użyj StyleCop”.

Zobacz: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx .

Muszę zasugerować dokument dotnetspider.com .
To wspaniały i szczegółowy dokument, który przyda się wszędzie.

Używałem już Juvala i to koniec, jeśli nie przesada, ale jestem leniwy i teraz po prostu podporządkowuję się woli Resharper .

Możesz sprawdzić to, 7 najważniejszych standardów kodowania i dokumentów z wytycznymi dla programistów C # / .NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html mam nadzieję, że to pomoże

Myślę, że powtarzam inne komentarze tutaj, że wytyczne stwardnienia rozsianego już połączone są doskonałym punktem wyjścia. W dużej mierze na nich wzoruję swój kod.

Co jest interesujące, ponieważ mój menedżer powiedział mi w przeszłości, że nie przepada za nimi: D

Masz przed sobą zabawne zadanie, przyjacielu. Powodzenia i zapytaj, czy potrzebujesz czegoś więcej :)

Standard opracowany przez firmę Philips Medical Systems jest dobrze napisany iw większości jest zgodny z wytycznymi firmy Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Moje standardy są na tym oparte z kilkoma poprawkami i kilkoma aktualizacjami dla .NET 2.0 (standard Philips jest napisany dla .NET 1.x, więc jest nieco przestarzały).

Ja też śledzę Resharper. Również przewodnik wspomniany na blogu Scotta Guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx i http://csharpguidelines.codeplex.com/releases/view/46280

W kodzie, który piszę, zazwyczaj kieruję się wytycznymi .NET Framework dotyczącymi projektowania publicznych interfejsów API oraz wytycznymi kodowania mono dla wielkości liter i wcięć elementów prywatnych . Mono to otwarta implementacja .NET i myślę, że ci faceci znają swój biznes.

Nienawidzę, jak kod Microsoft marnuje miejsce:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

To, co może wydawać się dziwne w wytycznych Mono, to fakt, że używają tabulatorów z 8 spacjami. Jednak po pewnym czasie odkryłem, że w rzeczywistości pomaga mi to w pisaniu mniej zagmatwanego kodu, egzekwując pewnego rodzaju limit wcięć.

Uwielbiam też to, jak wstawiają spację przed otwierającym nawiasem.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

Ale proszę, nie narzucaj niczego takiego, jeśli Twoi współpracownicy tego nie lubią (chyba że chcesz wnieść swój wkład w Mono ;-)