Standardy kodowania GNU
Standardy kodowania GNU to zbiór zasad i wskazówek dotyczących pisania programów , które działają spójnie w systemie GNU . Standardy kodowania GNU zostały napisane przez Richarda Stallmana i innych wolontariuszy Projektu GNU. Dokument standardów jest częścią Projektu GNU i jest dostępny na stronie internetowej GNU. Chociaż koncentruje się na pisaniu wolnego oprogramowania dla GNU w języku C , wiele z nich można zastosować bardziej ogólnie. W szczególności Projekt GNU zachęca swoich współtwórców, aby zawsze starali się przestrzegać standardów — niezależnie od tego, czy ich programy są implementowane w C.
Formatowanie kodu
Standardy kodowania GNU dokładnie określają sposób formatowania większości konstrukcji języka programowania C. Oto charakterystyczny przykład:
int main ( int argc , char * argv []) { struct gizmo foo ; fetch_gizmo ( & foo , argv [ 1 ]); sprawdź : if ( foo . type == MUMINKI ) puts ( "To muminek." ); inaczej if ( foo . bar <
0
GIZMO_SNUFKIN_THRESHOLD / 2 || ( strcmp ( foo . nazwa_klasy , "snufkin" ) == ) && foo . bar < GIZMO_SNUFKIN_THRESHOLD ) puts ( "To jest snufkin." ); else { char * barney ; /* Wskaźnik do pierwszego znaku po ostatnim ukośniku w nazwie pliku. */ wew
Wilma ; /* Przybliżona wielkość wszechświata. */ int fred ; /* Maksymalna wartość pola `bar'. */ do { frobnicate ( & foo , GIZMO_SNUFKIN_THRESHOLD , & barney , & wilma , & fred ); twiddle ( & foo , barney , wilma + fred ); } podczas (
0
fuj . słupek >= GIZMO_SNUFKIN_THRESHOLD ); store_size ( wilma ); idź sprawdzić ; } powrót ; }
Konsekwentne traktowanie bloków jako instrukcji (w celu wcięcia) jest bardzo charakterystyczną cechą stylu formatowania kodu GNU C; podobnie jak obowiązkowe miejsce przed nawiasami. Cały kod sformatowany w stylu GNU ma tę właściwość, że każdy nawias zamykający, nawias lub nawias pojawia się po prawej stronie odpowiadającego mu ogranicznika otwierającego lub w tej samej kolumnie.
Ogólną zasadą jest, że GNU Emacs może być rozważany [ przez kogo? ] wiarygodny autorytet w zakresie stylu formatowania kodu GNU. W związku z tym pożądane jest [ według kogo? ] , że każdy fragment kodu, który wygląda brzydko, gdy jest wcięty przez Emacsa, jest zmieniany w formę bardziej przyjazną dla Emacsa — na przykład przez wstawienie dodatkowych nawiasów.
Dzielenie długich linii
„Kiedy dzielisz wyrażenie na wiele wierszy, podziel je przed operatorem, a nie po jednym”.
Na przykład:
if ( foo_this_is_long && bar > wygrana ( x , y , z ) && warunek_pozostały )
Uwagi
Normy bardzo podkreślają znaczenie komentarzy w języku angielskim :
Proszę pisać komentarze w programie GNU po angielsku, ponieważ angielski jest jedynym językiem, który prawie wszyscy programiści we wszystkich krajach potrafią czytać. Jeśli nie piszesz dobrze po angielsku, pisz komentarze po angielsku tak dobrze, jak potrafisz, a następnie poproś inne osoby o pomoc w ich przepisaniu. Jeśli nie możesz pisać komentarzy po angielsku, znajdź kogoś do pracy i przetłumacz swoje komentarze na angielski.
Komentarze powinny składać się z pełnych zdań pisanych wielką literą, z których każde ma następującą spację (aby Emacs mógł stwierdzić, gdzie kończy się jedno zdanie, a zaczyna następne).
W przypadku długich lub złożonych warunków warunkowych preprocesora, każdy #else
i #endif
powinien mieć komentarz wyjaśniający warunek dla kodu poniżej (dla #else
) lub powyżej (dla #endif
).
Akta
Standardy wymagają, aby wszystkie programy mogły działać, gdy /usr
i /etc
są zamontowane tylko do odczytu. Dlatego pliki zmodyfikowane do celów wewnętrznych (pliki dziennika, pliki blokad, pliki tymczasowe itp.) nie powinny być przechowywane ani w /usr
, ani w /etc
. Wyjątek stanowią programy, których zadaniem jest aktualizacja plików konfiguracyjnych systemu w /etc
. Inny wyjątek dotyczy przechowywania plików w katalogu, gdy użytkownik wyraźnie poprosił o zmodyfikowanie pliku w tym samym katalogu.
Ruchliwość
Standardy kodowania GNU definiują kwestię przenośności w następujący sposób: przenośność w świecie Uniksa oznacza „pomiędzy Uniksami”; w programie GNU tego rodzaju przenośność jest pożądana, ale nie ma zasadniczego znaczenia.
Zgodnie ze standardem problemy z przenośnością są bardzo ograniczone, ponieważ programy GNU są zaprojektowane do kompilacji za pomocą jednego kompilatora, GNU C Compiler i działają tylko na jednym systemie, którym jest system GNU.
Istnieje jednak jedna forma problemu z przenośnością, a mianowicie fakt, że standard jasno określa, że program powinien działać na różnych typach procesorów . Standard mówi, że GNU nie obsługuje i nie będzie wspierać systemów 16-bitowych, ale obsługa wszystkich różnych systemów 32- i 64-bitowych jest absolutnie konieczna.
Krytyka
Standardy kodowania GNU są używane głównie w projektach GNU, chociaż ich użycie nie ogranicza się tylko do projektów GNU.
Jądro Linuksa zdecydowanie odradza ten styl kodu jądra i odnosi się do tego stylu pejoratywnie: „Po pierwsze, sugerowałbym wydrukowanie kopii standardów kodowania GNU i NIE ich czytanie. Spal je, to wspaniały gest symboliczny. ". Steve McConnell w swojej książce Code Complete również odradza używanie tego stylu; oznacza próbkę kodu, która go używa, ikoną „Coding Horror”, symbolizującą szczególnie niebezpieczny kod, i stwierdza, że utrudnia to czytelność, wymagając dodatkowego poziomu wcięcia dla nawiasów klamrowych.
Zobacz też
Linki zewnętrzne
- Standardy kodowania GNU na stronie internetowej GNU
- Eclipse Code Style Formatter dla standardów kodowania GNU