Możesz się zastanawiać, co oznacza tytuł. Kod to kod, prawda? Ważne jest, aby być wolnym od błędów i to wszystko, co jeszcze? Rozwój to coś więcej niż pisanie kodu i testowanie/debugowanie. Wyobraź sobie, że musisz przeczytać czyjąś pracę i przypuszczam, że już to zrobiłeś, a wszystkie zmienne nazywane są foo, bar, baz, var itp. A kod nie jest komentowany ani nie udokumentowany. Prawdopodobnie poczujesz nagłą potrzebę przywołania nieznanych bogów, a następnie pójść do lokalnego pubu i utopić swoje smutki. Mówią, że nie powinieneś robić innym tego, czego nie chcesz, więc ta część będzie koncentrować się na ogólnych wytycznych kodowania, a także pomysły specyficzne dla GNU, które pomogą ci zaakceptować kodeks. Powinieneś przeczytać i zrozumieć poprzednie części tej serii, a także rozwiązać wszystkie ćwiczenia i, najlepiej czytać i zapisać jak najwięcej kodu.

Zalecenia

Przed rozpoczęciem należy zwrócić uwagę na rzeczywiste znaczenie powyższego słowa. Nie chcę w żaden sposób powiedzieć, jak napisać swój kod, ani nie wymyślam tych zaleceń. Są to wynik lat pracy doświadczonych programistów, a wielu będzie miało zastosowanie nie tylko do C, ale do innych języków, zinterpretowanych lub skompilowanych.

Wydaje mi się, że pierwszą zasadą, którą chcę podkreślić, jest: skomentuj kod, a następnie sprawdź, czy skomentowałeś wystarczająco, a następnie skomentuj trochę więcej. Nie jest to korzystne dla innych, którzy odczytują/używają twojego kodu, ale także dla Ciebie. Być przekonanym, że nie pamiętasz, co dokładnie miałeś napisać po dwóch lub trzech miesiącach int ghrqa34; miał oznaczać, jeśli w ogóle. Dobrzy programiści komentują (prawie) każdą linię swojego kodu tak dokładnie, jak to możliwe, a wypłata jest większa niż na początku, pomimo zwiększonego czasu, aby napisać program. Kolejną zaletą jest to, że komentując, ponieważ tak działa nasz mózg, cokolwiek chcieliśmy zrobić, będzie lepiej zapamiętane, więc znowu nie spojrzysz na swój kod, szybkie do przodu, zastanawiając się, kto napisał twój kod. Lub dlaczego.

Parser C tak naprawdę nie dba o to, jak zamówić Twój kod. Oznacza to, że możesz napisać taki typowy program „Hello, World” i nadal by się skompilował:

#Include int main () printf („hello, świat!"); return 0; 

Wydaje się to o wiele bardziej czytelny sposób, w jaki napisaliśmy to po raz pierwszy, prawda?? Ogólne zasady dotyczące formatowania to: jedna instrukcja na wiersz, wybierz szerokość zakładki i bądź z nią spójny, ale upewnij się, że jest ona zgodna z wytycznymi projektu, jeśli pracujesz nad jednym, również liberalne użycie pustych linii, dla Wyznaczanie różnych części programu, wraz z komentarzami, a wreszcie, chociaż niekoniecznie jest to związane z stylem kodowania, zanim zaczniesz poważnie kodować, znajdź edytora, który lubisz i naucz się go dobrze używać. Wkrótce opublikujemy artykuł na temat redaktorów, ale do tego czasu Google pomoże Ci z niektórymi alternatywami. Jeśli słyszysz ludzi na forach, listach mailingowych itp. powiedzenie „redaktor X jest do bani, redaktor y ftw!", Ignoruj ​​ich. To bardzo subiektywna sprawa, a to, co jest dla mnie dobre, może nie być dla ciebie tak dobre, więc przynajmniej wypróbuj niektórych redaktorów dostępnych dla Linux na kilka dni, zanim zacząłem próbować tworzyć opinię.

Być spójne w nazwie zmiennych. Upewnij się również, że nazwy pasują do innych, więc w całym programie jest harmonia. Dotyczy to, nawet jeśli jesteś jedynym autorem oprogramowania, łatwiej będzie go utrzymać później. Utwórz listę używanych prefiksów i sufiksów (e.G. Max, min, zdobądź, ustaw, to, cnt) i idź z nimi, chyba że poproszono inaczej. Spójność jest tutaj kluczowym słowem.

Wytyczne specyficzne dla GNU

Poniżej znajduje się podsumowanie standardów kodowania GNU, ponieważ wiemy, że nie lubisz czytać takich rzeczy. Więc jeśli piszesz kod, który chciałby zmieścić się w ekosystemie GNU, jest to dokument do przeczytania. Nawet jeśli tego nie zrobisz, nadal jest to dobra lektura na temat pisania odpowiedniego kodu.

Ten dokument jest zawsze wart odczytania w całości, jeśli tworzysz lub utrzymujesz oprogramowanie GNU, ale poniżej znajdziesz najważniejsze części. Jednym z pierwszych problemów, o których warto wspomnieć o tym, jak radzić sobie z prototypami funkcji. Wróć do części zajmującej się tym, jeśli masz jakieś problemy. Pomysł brzmi: „Jeśli masz własne funkcje, użyj deklaracji prototypowej przed Main (), a następnie zdefiniuj funkcję w razie potrzeby.„Oto przykład:

#include int func (int, int) int main () […] int func (int x, int z) […] 

Użyj właściwego i ciągłego wcięcia. Nie można tego wystarczająco podkreślić. Doświadczeni programiści z latami kodeksu zabiorą to bardzo źle po przesłaniu kodu z niewłaściwym wcięciem. W naszym przypadku najlepszy sposób, aby przyzwyczaić się do tego, jak to jest GNU, używając GNU EMACS (chociaż nie jest to w żadnej formie, aby powiedzieć, że „GNU Emacs jest dla ciebie dobry, użyj go.”, Jak jesteśmy zwolennikami wolnej woli i wyboru), gdzie domyślnym zachowaniem kodu C jest ustawione w dwóch przestrzeniach i aparaty ortodontyczne na linii dla siebie. Co prowadzi nas do kolejnej ważnej kwestii. Niektórzy ludzie używają takich aparatów ortodontycznych:

chwila (var == 1) kod… 

… Podczas gdy inni, w tym ludzie GNU, robią to w ten sposób:

chwila (var == 1) kod…

Oczywiście dotyczy to również wyrażeń warunkowych, funkcji i każdej okazji, w której trzeba używać aparatów ortodontycznych w kodzie C. O ile zauważono, ten wybór jest czymś bardzo specyficznym dla GNU, a ile tego szanujesz, zależy wyłącznie od twojego gustu i postawy w tej sprawie.

Nasz kolejny problem jest techniczny i obietnica, którą musiałem zachować: problem Malloc (). Oprócz pisania istotnych i znaczących komunikatów o błędach, w przeciwieństwie do tych, które wszyscy widzieliśmy w innych systemach operacyjnych, sprawdź, czy Malloc () i przyjaciele zawsze zwracają zero. To są bardzo poważne problemy i otrzymasz kilka słów lekcja o Malloc () i kiedy z niej korzystać. Do tej pory wiesz, co przydzielanie pamięci automatycznie lub statycznie jest. Ale te metody nie obejmują wszystkich baz. Kiedy musisz przydzielić pamięć i mieć większą kontrolę nad operacją, istnieje Malloc () i przyjaciele, do dynamicznej alokacji. Jego celem jest przydzielenie dostępnej pamięci z sterta, Następnie program używa pamięci za pomocą wskaźnika, który zwraca Malloc (), a następnie wspomniana pamięć musi być wolna () d. I „musi” być napisane za pomocą stolic w literach 2 stóp o płonącym czerwonym kolorze. To dotyczy Malloc (), a przyczyny zostały już ujawnione wcześniej w poprzedniej części.

Zachęcamy do użycia spójnego interfejsu we wszystkich programach wiersza poleceń. Jeśli jesteś już doświadczonym użytkownikiem GNU/Linux, zauważyłeś, że prawie wszystkie programy mają -Version i -Help, a na przykład -v dla Portalnej, jeśli tak jest. Nie weźmiemy się w to wszystkiego; weź kopię standardów kodowania GNU, i tak go potrzebujesz.

Chociaż osobiście to przeoczam, a dla wielu jest to drobny problem, poprawi czytelność twojego kodu, ponieważ znowu tak działa nasz mózg. Chodzi o to: gdy masz wątpliwości co do korzystania z przestrzeni, użyj ich. Na przykład:

int func (var1, var2); int func (var1, var2);

Są takie, które mówią, że nie można uniknąć zagnieżdżonych ifs. Są inni, którzy mówią: „Po co unikać zagnieżdżonych ifs?”I są jeszcze inni, którzy po prostu nie używają zagnieżdżonych IFS. Stworzysz swoją własną opinię na ten temat w miarę upływu czasu i wierszy kodu, który piszesz wzrost. Chodzi o to, że jeśli ich użyjesz, uczyń je tak czytelnymi, jak to możliwe, ponieważ mogą one łatwo prowadzić do kodu prawie skaghetti, trudnego do odczytania i utrzymania. I ponownie użyj komentarzy.

Standard kodowania GNU mówi, że dobrze jest mieć tak przenośny kod, jak to tylko możliwe, „ale nie najważniejsze”. Przenośny sprzęt? To zależy od celu programu i tego, jakie maszyny masz do dyspozycji. Mówimy bardziej do strony oprogramowania, a mianowicie przenośność między systemami UNIX, open source lub nie. Unikaj ifdefs, jeśli możesz, unikaj założeń dotyczących lokalizacji plików (e.G. Solaris instaluje oprogramowanie stron trzecich Under /Opt, podczas gdy BSD i GNU /Linux nie) i ogólnie dąży do czystego kodu. Mówiąc o założeniach, nawet nie zakładaj, że bajt ma osiem bitów lub że przestrzeń adresu procesora musi być liczbą.

Dokumentowanie kodu, w formie ręcznych stron i dobrze napisanych readmes i tak dalej, jest kolejnym najważniejszym aspektem tworzenia oprogramowania. Tak, jest to żmudne zadanie, ale jeśli nie masz pisarza dokumentacji w swoim zespole, Twoim obowiązkiem jest to zrobić, ponieważ każdy dobry programista wykonuje swoją pracę od A do Z do Z.

Wniosek

Następnym razem będziemy kontynuować miejsce, w którym skończyliśmy tutaj: przejście od pomysłu do kompletnego programu, z Makefiles, Dokumentacja, Cykle uwalniania i wszystkie zabawne rzeczy. Jedynym ćwiczeniem, które mam dla ciebie, jest przeglądanie standardów kodowania GNU i modyfikowanie kodu jako zgodności. I przygotuj się, następnym razem, gdy będzie zabawny czas!

Oto, czego możesz się spodziewać następnego:

• I. C Opracowanie w Linux - Wprowadzenie
• Ii. Porównanie C i innych języków programowania
• Iii. Typy, operatorzy, zmienne
• Iv. Kontrola przepływu
• V. Funkcje
• Vi. Wskaźniki i tablice
• VII. Struktury
• VIII. Podstawowe I/O
• IX. Styl kodowania i zalecenia
• X. Budowanie programu
• Xi. Opakowanie dla Debiana i Fedory
• XII. Uzyskanie pakietu w oficjalnych repozytoriach Debiana

Powiązane samouczki Linux:

• Samouczek debugowania GDB dla początkujących
• Zainstaluj Arch Linux na stacji roboczej VMware
• Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
• Rzeczy do zainstalowania na Ubuntu 20.04
• Wyrażenia regularne Pythona z przykładami
• Jak zbudować aplikację Tkinter za pomocą obiektu zorientowanego na…
• Advanced Bash Regex z przykładami
• Pętle bash z przykładami
• Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
• Zagnieżdżone pętle w skryptach Bash