Ta sekcja jest również tak naprawdę warunkiem wstępnym kodowania, jak podkreśla McConnell: „ustal konwencje programowania przed rozpoczęciem programowania. Jest prawie niemożliwe, aby zmienić kod, aby dopasować je później.”

jak podano pod koniec konwencji kodowania, istnieją różne konwencje dla różnych języków programowania, więc stosowanie tych samych konwencji w różnych językach może być odwrotne do zamierzonego. Ważne jest, aby pamiętać, że nie ma jednej konkretnej konwencji kodowania dla żadnego języka programowania. Każda organizacja ma niestandardowy standard kodowania dla każdego typu projektu oprogramowania. Dlatego konieczne jest, aby programista wybrał lub wymyślił określony zestaw wytycznych dotyczących kodowania przed rozpoczęciem projektu oprogramowania. Niektóre konwencje kodowania są ogólne, które mogą nie mieć zastosowania do każdego projektu oprogramowania napisanego w danym języku programowania.

stosowanie konwencji kodowania jest szczególnie ważne, gdy projekt angażuje więcej niż jednego programistę (były projekty z tysiącami programistów). Znacznie łatwiej jest programiście odczytać kod napisany przez kogoś innego, jeśli cały kod jest zgodny z tymi samymi konwencjami.

dla niektórych przykładów złych konwencji kodowania, Roedy Green dostarcza obszerny (z języczkiem) artykuł o tym, jak stworzyć nieosiągalny kod.

Komentowanieedit

ze względu na ograniczenia czasowe lub entuzjastycznych programistów, którzy chcą natychmiastowych wyników dla swojego kodu, komentowanie kodu często zajmuje tylne miejsce. Programiści pracujący jako zespół stwierdzili, że lepiej zostawić komentarze, ponieważ kodowanie zwykle następuje po cyklach, lub więcej niż jedna osoba może pracować nad danym modułem. Jednak niektóre komentarze mogą obniżyć koszty transferu wiedzy między programistami pracującymi nad tym samym modułem.

w początkach informatyki jedną z praktyk komentowania było pozostawienie krótkiego opisu następujących:

1. nazwa modułu
2. przeznaczenie modułu
3. opis modułu
4. oryginalny autor
5. Modyfikacje
6. autorzy, którzy zmodyfikowali kod wraz z opisem dlaczego został zmodyfikowany.

„opis modułu” powinien być jak najkrótszy, ale bez poświęcania jasności i kompleksowości.

jednak ostatnie dwa elementy zostały w dużej mierze zdezaktualizowane w związku z pojawieniem się systemów kontroli wersji. Modyfikacje i ich autorstwo można wiarygodnie śledzić za pomocą takich narzędzi, a nie za pomocą komentarzy.

Ponadto, jeśli używana jest skomplikowana logika, dobrą praktyką jest pozostawienie komentarza „blokuj” w pobliżu tej części, aby inny programista mógł zrozumieć, co dokładnie się dzieje.

testowanie jednostkowe może być kolejnym sposobem pokazania, w jaki sposób kod ma być używany.

konwencje Nazewnictwaedytuj

stosowanie odpowiednich konwencji nazewnictwa jest uważane za dobrą praktykę. Czasami programiści mają tendencję do używania X1, Y1, itp. jako zmienne i zapomnij zastąpić je znacznymi, powodując zamieszanie.

zwykle za dobrą praktykę uważa się używanie nazw opisowych.

przykład: zmienna do przyjmowania wagi jako parametru dla ciężarówki może być nazwana Trkweightkilograms lub TruckWeightKilograms, przy czym preferowane są TruckWeightKilograms, ponieważ jest natychmiast rozpoznawalna. Zobacz CamelCase nazewnictwo zmiennych.

zachowaj prosty kodedytuj

kod, który programista pisze powinien być prosty. Skomplikowana logika osiągnięcia prostej rzeczy powinna być ograniczona do minimum, ponieważ kod może być modyfikowany przez innego programistę w przyszłości. Logika zaimplementowana przez jednego programistę może nie mieć idealnego sensu dla drugiego. Tak więc zawsze zachowaj kod tak prosty, jak to tylko możliwe.

na przykład rozważ te równoważne linie kodu C:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

i

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

i

return hours < 24 && minutes < 60 && seconds < 60;

pierwsze podejście, które jest znacznie częściej stosowane, jest znacznie większe niż trzecie. W szczególności zużywa 5 razy więcej pionowej przestrzeni ekranu (linii) i 97 znaków w porównaniu z 52 (chociaż narzędzia edycyjne mogą zmniejszyć różnicę w faktycznym pisaniu). Jest to jednak wątpliwe, co jest „prostsze”. Pierwszy ma jawne if/Then else, z jawną wartością zwracaną oczywiście związaną z każdym; nawet początkujący programista nie powinien mieć trudności ze zrozumieniem tego. Drugi po prostu odrzuca szelki, przecinając” pionowy ” rozmiar na pół z niewielką zmianą w złożoności pojęciowej. W większości języków polecenia „return”mogą być również dołączane do wcześniejszych linii, przynosząc” pionowy ” rozmiar Tylko do jednej linii więcej niż w trzeciej formie.

trzecia forma oczywiście minimalizuje rozmiar, ale może zwiększyć złożoność: Pozostawia wartości” true „I” false „niejawne i łączy pojęcia” condition „I”return value”. Jest to prawdopodobnie oczywiste dla większości programistów, ale początkujący może nie od razu zrozumieć, że wynikiem oceny warunku jest w rzeczywistości wartość (typu Boolean lub jej odpowiednik w jakimkolwiek języku), a zatem może być manipulowany lub zwracany. W bardziej realistycznych przykładach, trzecia forma może mieć problemy z powodu pierwszeństwa operatora, być może zwracając nieoczekiwany Typ, gdzie wcześniejsze formy w niektórych językach zgłaszałyby błąd. Tak więc „prostota” nie jest tylko kwestią długości, ale logicznej i pojęciowej struktury; skrócenie kodu może uczynić go mniej lub bardziej złożonym.

dla dużych, długowiecznych programów używających gadatliwych alternatyw może przyczynić się do wzdęcia.

zwartość może pozwolić koderom na wyświetlanie większej ilości kodu na stronę, zmniejszając gesty przewijania i naciśnięcia klawiszy. Biorąc pod uwagę, ile razy kod może być oglądany w procesie pisania i utrzymywania, może to oznaczać znaczne oszczędności w naciśnięciach klawiszy programisty w życiu kodu. Może to nie wydawać się istotne dla ucznia, który najpierw uczy się programowania, ale podczas produkcji i utrzymywania dużych programów zmniejszenie liczby linii kodu pozwala na zmieszczenie większej części kodu na ekranie, drobne uproszczenie kodu może poprawić wydajność, a także zmniejszyć zmęczenie palców, nadgarstków i oczu, które są powszechnymi problemami medycznymi, które cierpią koderzy produkcyjni i pracownicy informacyjni.

kodowanie Tersera przyspiesza kompilację bardzo nieznacznie, ponieważ trzeba przetwarzać mniej symboli. Co więcej, trzecie podejście może pozwolić na łatwiejsze porównywanie podobnych linii kodu, szczególnie gdy wiele takich konstrukcji może pojawić się na jednym ekranie w tym samym czasie.

wreszcie, bardzo terses layouts może lepiej wykorzystać nowoczesne wyświetlacze szerokoekranowe komputera, w zależności od układu monitora i konfiguracji. W przeszłości ekrany były ograniczone do 40 lub 80 znaków (takie ograniczenia powstały znacznie wcześniej: rękopisy, drukowane książki, a nawet zwoje, od tysiącleci używały dość krótkich linii (patrz np. Biblia Gutenberga). Nowoczesne ekrany mogą z łatwością wyświetlać 200 lub więcej znaków, umożliwiając wyjątkowo długie linie. Większość nowoczesnych stylów i standardów kodowania nie zajmuje całej szerokości. Tak więc, jeśli używasz jednego okna tak szerokiego jak ekran, marnuje się dużo dostępnej przestrzeni. Z drugiej strony, w przypadku wielu okien lub przy użyciu IDE lub innego narzędzia z różnymi informacjami w panelach bocznych, dostępna szerokość kodu mieści się w zakresie znanym z wcześniejszych systemów.

warto również zauważyć, że na ludzki układ wzrokowy ma duży wpływ długość linii; bardzo długie linie nieznacznie zwiększają szybkość czytania, ale zmniejszają zrozumienie i zwiększają błędy śledzenia wzroku. Niektóre badania sugerują, że dłuższe linie lepiej radzą sobie w Internecie niż w druku, ale to wciąż sięga tylko do około 10 cali, a głównie dla szybkości czytania prozy.

Przenośnośćedit

kod programu nie powinien zawierać „zakodowanych” (dosłownych) wartości odnoszących się do parametrów środowiskowych, takich jak bezwzględne ścieżki plików, nazwy plików, nazwy użytkowników, nazwy hostów, adresy IP, adresy URL, porty UDP / TCP. W przeciwnym razie aplikacja nie będzie działać na hoście o innej konstrukcji niż przewidywano. Ostrożny programista może parametryzować takie zmienne i konfigurować je dla środowiska hostingowego poza właściwą aplikacją (na przykład w plikach właściwości, na serwerze aplikacji, a nawet w bazie danych). Porównaj mantrę „pojedynczego punktu definicji” (SPOD).

jako rozszerzenie, zasoby takie jak pliki XML powinny również zawierać zmienne, a nie wartości dosłowne, w przeciwnym razie aplikacja nie będzie przenośna do innego środowiska bez edycji plików XML. Na przykład w przypadku aplikacji J2EE uruchomionych w serwerze aplikacji takie parametry środowiskowe można zdefiniować w zakresie JVM i aplikacja powinna stamtąd pobierać wartości.

Skalowalnośćedytuj

kod projektowy ze skalowalnością jako celem projektu, ponieważ bardzo często w projektach programistycznych nowe funkcje są zawsze dodawane do projektu, który staje się większy. Dlatego możliwość dodawania nowych funkcji do bazy kodu oprogramowania staje się nieocenioną metodą pisania oprogramowania

ReusabilityEdit

ponowne użycie jest bardzo ważnym celem projektowym w tworzeniu oprogramowania. Ponowne użycie zmniejsza koszty rozwoju, a także skraca czas rozwoju, jeśli komponenty lub moduły, które są ponownie używane, są już przetestowane. Bardzo często Projekty oprogramowania rozpoczynają się od istniejącej linii bazowej, która zawiera projekt w jego wcześniejszej wersji i w zależności od projektu wiele istniejących modułów i komponentów oprogramowania jest ponownie wykorzystywanych, co skraca czas opracowywania i testowania, zwiększając prawdopodobieństwo dostarczenia projektu oprogramowania zgodnie z harmonogramem.

wytyczne budowlane w skrócie

ogólny przegląd wszystkich powyższych: