Konwencje kodowania - Coding conventions

Rozwój oprogramowania
Główne działania
Paradygmaty i modele
Metodologie i ramy
Dyscypliny wspierające
Praktyki
Narzędzia
Standardy i zbiory wiedzy
Glosariusze
Wytyczne

Konwencje kodowania to zestaw wytycznych dla określonego języka programowania, które zalecają styl programowania , praktyki i metody dla każdego aspektu programu napisanego w tym języku. Konwencje te zazwyczaj obejmują organizację plików, wcięcia , komentarze , deklaracji , oświadczeń , białe znaki , konwencje nazewnictwa , programowanie praktyk , programowanie zasad , programowania zasady kciuka , najlepszych praktyk architektonicznych itd Są to wytyczne dla jakości oprogramowania strukturalnego . Programistów są zalecane do poniższych wskazówek, aby poprawić czytelność ich kodu źródłowego i dokonać konserwacji oprogramowania łatwiejsze. Konwencje kodowania mają zastosowanie tylko do ludzkich opiekunów i recenzentów projektu oprogramowania. Konwencje mogą być sformalizowane w udokumentowanym zestawie zasad, których przestrzega cały zespół lub firma, lub mogą być tak nieformalne, jak zwyczajowe praktyki kodowania poszczególnych osób. Konwencje kodowania nie są wymuszane przez kompilatory .

Konserwacja oprogramowania

Zmniejszenie kosztów utrzymania oprogramowania to najczęściej przytaczany powód przestrzegania konwencji kodowania. We wprowadzeniu do konwencji kodu dla języka programowania Java firma Sun Microsystems podaje następujące uzasadnienie:

Konwencje kodowe są ważne dla programistów z kilku powodów:

  • 40%–80% kosztów eksploatacji oprogramowania przez cały okres użytkowania jest przeznaczane na konserwację.
  • Prawie żadne oprogramowanie nie jest utrzymywane przez całe życie przez oryginalnego autora.
  • Konwencje kodu poprawiają czytelność oprogramowania, umożliwiając inżynierom szybsze i dokładniejsze zrozumienie nowego kodu.
  • Jeśli wysyłasz kod źródłowy jako produkt, musisz upewnić się, że jest on tak dobrze zapakowany i czysty, jak każdy inny tworzony przez Ciebie produkt.

Jakość

Weryfikacja oprogramowania często wiąże się z odczytaniem kodu źródłowego. Ten rodzaj wzajemnej oceny to przede wszystkim działanie polegające na wykrywaniu defektów . Z definicji tylko oryginalny autor fragmentu kodu przeczytał plik źródłowy przed przesłaniem kodu do recenzji. Kod napisany przy użyciu spójnych wytycznych jest łatwiejszy do zrozumienia i przyswojenia przez innych recenzentów, co poprawia skuteczność procesu wykrywania defektów.

Nawet dla oryginalnego autora konsekwentnie kodowane oprogramowanie ułatwia konserwację. Nie ma gwarancji, że dana osoba zapamięta dokładne uzasadnienie, dlaczego dany fragment kodu został napisany w określony sposób, długo po jego pierwotnym napisaniu. Pomocne mogą być konwencje kodowania. Konsekwentne stosowanie białych znaków poprawia czytelność i skraca czas potrzebny na zrozumienie oprogramowania.

Standardy kodowania

Tam, gdzie konwencje kodowania zostały specjalnie zaprojektowane do tworzenia kodu wysokiej jakości, a następnie zostały formalnie przyjęte, stają się standardami kodowania. Określone style, niezależnie od tego, czy są powszechnie stosowane, nie tworzą automatycznie kodu dobrej jakości.

Redukcja złożoności

Złożoność jest czynnikiem zagrażającym bezpieczeństwu.

Zarządzanie złożonością obejmuje następującą podstawową zasadę: minimalizuj ilość kodu napisanego podczas tworzenia projektu. Zapobiega to niepotrzebnej pracy, co zapobiega niepotrzebnym kosztom, zarówno początkowym, jak i końcowym. Dzieje się tak dlatego, że im mniej kodu, tym mniej pracy wymaga nie tylko tworzenie aplikacji, ale także jej utrzymanie.

Złożoność jest zarządzana zarówno na etapie projektowania (jak projekt jest zaprojektowany) jak i na etapie rozwoju (poprzez posiadanie prostszego kodu). Jeśli kodowanie będzie proste i proste, złożoność zostanie zminimalizowana. Bardzo często jest to utrzymywanie kodowania tak „fizycznego”, jak to tylko możliwe – kodowanie w sposób bardzo bezpośredni i niezbyt abstrakcyjny. Daje to optymalny kod, który jest łatwy do odczytania i naśladowania. Złożoności można również uniknąć, po prostu nie używając skomplikowanych narzędzi do prostych prac.

Im bardziej złożony kod, tym większe prawdopodobieństwo, że zawiera on błędy, tym trudniej je znaleźć i tym bardziej prawdopodobne jest, że są ukryte.

Refaktoryzacja

Refaktoryzacja odnosi się do czynności związanych z konserwacją oprogramowania, w których kod źródłowy jest modyfikowany w celu poprawy czytelności lub ulepszenia jego struktury. Oprogramowanie jest często refaktoryzowane w celu dostosowania go do standardów kodowania określonych przez zespół po jego pierwszym wydaniu. Każda zmiana, która nie zmienia zachowania oprogramowania, może zostać uznana za refaktoryzację. Typowe czynności refaktoryzacji to zmiana nazw zmiennych, zmiana nazw metod, przenoszenie metod lub całych klas oraz dzielenie dużych metod (lub funkcji ) na mniejsze.

Zwinne metodyki tworzenia oprogramowania przewidują regularną (lub nawet ciągłą) refaktoryzację, czyniąc ją integralną częścią procesu tworzenia oprogramowania zespołowego .

Automatyzacja zadań

Konwencje kodowania pozwalają programistom mieć proste skrypty lub programy, których zadaniem jest przetwarzanie kodu źródłowego w innym celu niż kompilacja go do pliku wykonywalnego. Powszechną praktyką jest liczenie rozmiaru oprogramowania ( wiersze kodu źródłowego ) w celu śledzenia bieżącego postępu projektu lub ustalenia punktu odniesienia dla przyszłych szacunków projektu .

Spójne standardy kodowania mogą z kolei sprawić, że pomiary będą bardziej spójne. Specjalne znaczniki w komentarzach do kodu źródłowego są często używane do przetwarzania dokumentacji, dwa godne uwagi przykłady to javadoc i doxygen . Narzędzia określają użycie zestawu tagów, ale ich użycie w projekcie jest zdeterminowane konwencją.

Konwencje kodowania upraszczają pisanie nowego oprogramowania, którego zadaniem jest przetwarzanie istniejącego oprogramowania. Wykorzystanie statycznej analizy kodu stale rosło od lat pięćdziesiątych. Część rozwoju tej klasy narzędzi programistycznych wynika z większej dojrzałości i wyrafinowania samych praktyków (i współczesnego skupienia się na bezpieczeństwie i zabezpieczeniach ), ale także z natury samych języków.

Czynniki językowe

Wszyscy praktycy oprogramowania muszą zmagać się z problemem organizowania i zarządzania dużą liczbą czasami skomplikowanych instrukcji. W przypadku wszystkich, z wyjątkiem najmniejszych projektów oprogramowania, kod źródłowy (instrukcje) są podzielone na osobne pliki i często w wielu katalogach . Naturalnym było, że programiści zbierali ściśle powiązane funkcje (zachowania) w tym samym pliku i gromadzili powiązane pliki w katalogach. W miarę jak rozwój oprogramowania przesunął się z programowania czysto proceduralnego (takiego jak w FORTRAN ) w kierunku konstrukcji bardziej obiektowych (takich jak w C++ ), praktyką stało się pisanie kodu dla pojedynczej (publicznej) klasy w jednym pliku ( Konwencja „jedna klasa na plik”). Java poszła o krok dalej — kompilator Java zwraca błąd, jeśli znajdzie więcej niż jedną klasę publiczną na plik.

Konwencja w jednym języku może być wymogiem w innym. Konwencje językowe mają również wpływ na poszczególne pliki źródłowe. Każdy kompilator (lub interpreter) używany do przetwarzania kodu źródłowego jest unikalny. Reguły, które kompilator stosuje do źródła, tworzą niejawne standardy. Na przykład kod Pythona jest znacznie bardziej konsekwentnie wcięty niż, powiedzmy, Perl, ponieważ białe znaki (wcięcia) są w rzeczywistości istotne dla interpretera. Python nie używa składni nawiasów klamrowych, której Perl używa do rozgraniczania funkcji. Jako ograniczniki służą zmiany wcięć. Tcl , który używa składni nawiasów klamrowych podobnej do Perla lub C/C++ do rozgraniczenia funkcji, nie pozwala na następujące, co wydaje się całkiem rozsądne dla programisty C: 

 set i = 0
 while {$i < 10} 
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }

Powodem jest to, że w Tcl nawiasy klamrowe nie są używane tylko do rozgraniczenia funkcji, jak w C lub Javie. Bardziej ogólnie, nawiasy klamrowe służą do grupowania słów w jeden argument. W Tcl słowo while przyjmuje dwa argumenty, warunek i akcję . W powyższym przykładzie, gdy brakuje drugiego argumentu, jego akcji (ponieważ Tcl używa również znaku nowej linii do odgraniczenia końca polecenia).

Wspólne konwencje

Istnieje wiele konwencji kodowania; zobacz Styl kodowania po liczne przykłady i dyskusję. Wspólne konwencje kodowania mogą obejmować następujące obszary:

Standardy kodowania obejmują CERT C Coding Standard , MISRA C , High Integrity C++ , patrz lista poniżej.

Zobacz też

Bibliografia

  1. ^ "EditorConfig pomaga programistom definiować i utrzymywać spójne style kodowania między różnymi edytorami i środowiskami IDE" . EditorConfig .
  2. ^ „Konwencje kodu dla języka programowania Java: po co stosować konwencje kodu” . Sun Microsystems, Inc. 1999-04-20.
  3. ^ Robert L. Glass: Fakty i błędy inżynierii oprogramowania; Addisona Wesleya, 2003.
  4. ^ Tom Gillis. „Złożoność jest wrogiem bezpieczeństwa” .
  5. ^ Jeffries, Ron (2001-11-08). „Co to jest programowanie ekstremalne? : Ulepszanie projektu” . Magazyn XP. Zarchiwizowane z oryginału w dniu 2006-12-15.
  6. ^ Hoff, Todd (2007-01-09). "Standard kodowania C++: Nazywanie plików klas" .
  7. ^ Standardy kodowania FIFE
  8. ^ van Rossum, Guido (2006-09-19). Fred L. Drake, Jr (red.). "Samouczek Pythona: Pierwsze kroki w kierunku programowania" . Fundacja Oprogramowania Pythona. Zarchiwizowane z oryginału dnia 2008-09-28 . Pobrano 17.08.2014 .
  9. ^ Raymond Eric (2000-05-01). „Dlaczego Pythona?” . Dziennik Linuksa.
  10. ^ Xchange dla programistów Tcl. "Podsumowanie składni języka Tcl" . Stan aktywny.
  11. ^ Staplin, George Peter (2006-07-16). "Dlaczego nie mogę rozpocząć nowej linii przed grupą zastrzałów" . „Wiki Tclera”.

Lista standardów kodowania

Konwencje kodowania dla języków

Konwencje kodowania dla projektów

  1. ^ "Standard kodowania TIOBE - C" . tics.tiobe.com . Pobrano 2021-03-11 .
  2. ^ "Standard kodowania C++" . tics.tiobe.com . Pobrano 2021-03-11 .
  3. ^ "Standard kodowania C#" . tics.tiobe.com . Pobrano 2021-03-11 .
  4. ^ „TIOBE — standard kodowania Java” . tics.tiobe.com . Pobrano 2021-03-11 .