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


159

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ś?

Odpowiedzi:




26

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.


14

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ć.


9

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.


9

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.


8

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


5

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.


1
IntelliSense w Visual Studio 2010 pozwala wpisać „Name” i będzie on pasował podciąg w p_strName- robi to 10% mniej bolesne, gdy jesteś zmuszony do pracy z taką obrzydliwość. : o
Sam Harwell

5

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ć;)


2
Już miałem zasugerować tę samą książkę. Musisz to przeczytać.
Pascal Paradis

Jestem w trakcie czytania książki, przeczytałem> 67%. To zmieniło sposób, w jaki wyobrażam sobie programowanie. Musisz przeczytać.
UrsulRosu

4

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


4

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/


2
Możesz nie zgadzać się ze wszystkim, co wymusza StyleCop, ale weź pod uwagę, że Microsoft zmierza w kierunku jednego standardu, narzuconego przez StyleCop - więc jest to zestaw standardów, które mogą znać inni programiści. Spójność z większością reszty branży może być cenna.
Bevan

4

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.


4

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ę .....


NAPRAWDĘ podoba mi się ten przewodnik i myślę, że ma fantastyczny format (szybka wersja i pełna wersja, jak wielu ludzi, których widziałem). Masz mój głos przeciwko wszystkim innym, dobra robota. Gorąco polecam użycie tego dokumentu na Codeplex jako początek, ponieważ jest to naprawdę dobry przewodnik do porównywania notatek lub uważnego śledzenia.
atconway

Widziałem to. Naprawdę mam to na myśli, kontynuuj dobrą pracę i polecam ten przewodnik przynajmniej jako punkt wyjścia dla poważnych programistów .NET.
atconway

1
+1 za świetną robotę, szkoda, że ​​nie mogę +100. Jest krótki, więc ludzie faktycznie go przeczytają - więc wygrywa standardy Microsoft i IDesign. Zawiera znaczące nazwy reguł, ściągawkę, pliki stylów dla VS / R # ... może brakuje bardziej rozbudowanych przykładów w ściągawce :)
Victor Sergienko


1

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.


Nie zgadzam się. Najgorsze, co może się zdarzyć, to niespójność wytycznych; i omijają błędy. Jeśli zdarzy się, że pisze oprogramowanie sterujące dla LHC, jesteśmy f'd. / Sarkazm
TraumaPony,


1

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.





1

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



0

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 :)


0

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).



0

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 ;-)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.