Programowanie w języku Delphi » Delphi 7. Kompendium programisty

Dodatek A. Zasady pisania kodu

  • 2013-09-30 09:06
  • 2 komentarze
  • 3361 odsłon
  • Oceń ten tekst jako pierwszy
Istnieje jeszcze jedna kwestia, z pozoru niezbyt istotna — zasady pisania kodu źródłowego. Dla kompilatora nie jest istotne, jak wygląda kod — czy jest zapisany dużymi, czy małymi literami. Jednak dla innych programistów, którzy czytają Twój kod, jego wygląd może być błogosławieństwem lub przekleństwem. Często można się natknąć na zapisywanie kodu źródłowego tak, jakby stanowił zwykły zbiór poleceń. Taki zapis jest nieczytelny dla innych programistów (w przypadku, gdy udostępniasz go innym osobom) i wręcz niedopuszczalny, jeżeli pracujesz w zespole. Dlatego też powstał standard kodowania Object Pascala, który wyznaczyli programiści firmy Borland, pisząc kod VCL. Ja sam staram się stosować te reguły i pisać jak najczytelniejszy kod — to samo zalecam Tobie, drogi Czytelniku.

Spójrz na poniższy kod:

procedure costam;
var
i:integer;
begin
for i:=0 to 100 do begin
if i=50 then
  memo1.lines.add('jest już polowa...');
end;
end;


Uwierz mi, że taki kod jest mało czytelny, niepraktyczny i niezbyt przejrzysty. Teraz porównaj to z kodem zapisanym poniżej:

procedure CosTam;
var
  I : Integer;
begin
  for I := 0 to 100 do
  begin
    if i=50 then
       Memo1.Lines.Add('jest już polowa...');
  end;
end;


Teraz odpowiedz sobie sam na pytanie: jaki zapis wolisz?

Stosowanie wcięć


Przyjęło się stosowanie wcięć wielkości dwóch spacji. Naturalnie nie stosuje się wcięć w każdym wersie — można powiedzieć, że wcięcia na pewno powinny się znaleźć w bloku begin..end:

begin
  ShowMessage('Dwie spacje');
end;


Jak widzisz, polecenie ShowMessage zostało zapisane z użyciem dwóch spacji. Kolejny przykład:

begin
  if X < 10 then
  begin
    if Y > 100 then
    begin
 
    end;
  end;
end;


Zwróć uwagę: każdy blok begin to kolejne wcięcia, natomiast słowo end jest na tej samej „wysokości” co odpowiadające mu słowo begin.

Instrukcje begin i end


Nie pisz w ten sposób:

if X = 10 then begin


Zasadą jest, aby słowo begin znajdowało się pod spodem, a nie w tym samym wierszu, razem ze słowem then. Słowo end natomiast powinno być w tej samej kolumnie co słowo begin (tak, jak wspominałem w powyższym punkcie):

if X = 10 then
begin
  { jakieś instrukcje }
  if Zamien = TRUE then
  begin
    { jakieś instrukcje }
  end;
end;


Styl wielbłądzi w nazwach procedur


Jeżeli nazwa procedury lub funkcji jest dłuższa, bo zawiera np. kilka wyrazów ze sobą połączonych, to warto ją pisać tzw. stylem wielbłądzim (każdy wyraz składowy zaczynając wielką literą) — np:

procedure MojaPierwszaProceduraNapisanaStylemWielbladzim;


Wygląda to lepiej niż:

procedure mojapierwszaproceduranapisanastylemwielbladzim;


To samo tyczy się nazw funkcji oraz zmiennych.

Stosuj wielkie litery


Tak, jak w języku polskim, również w Pascalu wyraz następujący po kropce pisze się wielką literą — spójrz na poniższą instrukcję:

Memo1.Lines.Add('to jest tekst?');


Nie uważasz, że tak zapisane instrukcje wyglądają lepiej niż poniższe:

memo1.lines.add('to jest tekst? ');


O wiele lepiej wygląda, prawda? Bardziej przejrzyście. To samo tyczy się nazw zmiennych:

var
  Imie        :    String;
  Nazwisko    :    String;
  Kod         :    Integer;


Prawda, że wygląda lepiej? Szczególnie z dwukropkiem umieszczonym w tej samej kolumnie. Wyjątkiem przy stosowaniu wielkich liter są słowa kluczowe, które Delphi pogrubia ? powinny być one zapisywane małymi literami.

Parametry procedur


Parametry o identycznym typie powinny być zgrupowane w pojedynczej deklaracji — zamiast więc pisać tak:

procedure Moja(Param1: String; Param2: String; Pararm3: String);


możesz napisać tak:

procedure Moja(Param1, Param2, Param3 : String);


Instrukcja if


Tak, jak już wcześniej napisałem, słowo begin należy umieszczać zaraz poniżej if. Ale co wtedy, gdy trzeba dodać jeszcze słowo else? Może to wyglądać tak:

if X = 10 then
begin
  { coś tam }
end else
  { jeszcze coś }


Jeżeli zechcesz po słowie else dodać jeszcze begin, może to wyglądać tak:

if X = 10 then
begin
  { coś tam }
end else
begin
  { jeszcze coś }
end;
lub:
if X = 10 then
begin
  { coś tam }
end
else begin
  { jeszcze coś }
end;


Ja wolę stosować pierwszy wariant ze słowem begin umieszczonym niżej.

Instrukcja case


Oto propozycja pisania instrukcji case:

case i of
  1:
     begin
 
     end;
  2:
     begin
 
     end;
end;


Obsługa wyjątków


Zaleca się podczas tworzenia jakiegoś obiektu uwzględnić wystąpienie wyjątku i odpowiednio nań zareagować, np.:

Reg := TRegistry.Create;
try
  { niezbędne operacje }
finally
  Reg.Free; // zwolnienie obiektu, nawet gdy wystapił wyjątek
end;


Zwróć również uwagę na styl zapisywania i użycie wcięć.

Klasy


Każdą klasę (nazwę) należy poprzedzić literą T. Jest to bardzo ważna reguła. Np. deklaracja nazwy powinna wyglądać tak:

type
  TKlasa = class(TObject);


A zmienna wskazująca tę klasę powinna wyglądać tak:

var Klasa : TKlasa;


Zawsze zapisuje się to, pomijając pierwszą literę T.

Komentarze


Wierz mi, że komentarze są bardzo ważnym elementem języka Object Pascal. Być może po napisaniu jakiegoś programu i powróceniu do niego po np. dwóch miesiącach nie będziesz pamiętał, jak doszedłeś do tej, czy innej funkcji, jak jest wykonywana jakaś procedura itp. Warto więc komentować kod.

Na samym początku każdego pliku źródłowego warto też umieścić informacje o jego nazwie oraz prawach autorskich — np.:

(********************************************************)
(*               Moja aplikacja v. 1.0                          *)
(*         Copyright © 2003 by Adam Boduch              *)
(*                http://boduch.net                     *)
(********************************************************)


Pliki i nazwy formularzy


Tak, jak większość programistów, do nazwy formularza dodaję końcówkę Form. Np. główny formularz w programie powinien mieć nazwę MainForm, a zapisany plik formularza ? nazwę MainFrm.pas (z końcówką Frm). Jeżeli więc stworzysz formularz O programie, jego nazwą może być AboutForm, a zapisany plik może być nazwany AboutFrm.pas.

Unikaj nazewnictwa Unit1.pas, Unit2.pas — jest to przejaw amatorszczyzny

Również główny plik projektu (z rozszerzeniem .DPR ) powinien mieć jakąś umowną nazwę, np. skrót od nazwy programu lub samą nazwę programu, np. PerlEditor.

Notacja węgierska


Notacja węgierska jest techniką nazewnictwa komponentów oraz zmiennych. Przyznam szczerze, że nie zawsze ją stosuję, ale jest to także przydany sposób zwiększenia przejrzystości kodu. Polega na stosowaniu prefiksów — przykładowo przed zmienną, która jest typu Integer, dodajemy prefiks i (np. iCounter). Zalecane prefiksy przedstawiam w tabelach A.1 i A.2.

Tabela A.1. Prefiksy stosowane w stosunku do zmiennych
PrefiksZmienna
iInteger
iCardinal
iLongint
wWord
dwDWORD
s, strString
c, chChar
pcPChar
bBoolean


Tabela A.2. Prefiksy popularnych komponentów
PrefiksNawa komponentu
mmTMainMenu
mmiTMainMenuItem
pmTPopupMenu
pmiTPopupMenuItem
lblTLabel
btnTButton
edtTEdit
memTMemo
cbTCheckBox
rbTRadioButton
lbTListBox
cbTComboBox
pnlTPanel


Czy warto?


Pewnie powiesz: „nie chce mi się stosować takiego stylu”. Pewnie wydaje Ci się, że stosowanie tych zasad w praktyce spowoduje, że pisanie kodu zajmie Ci więcej czasu, lecz to tylko pozory. Jeżeli dużo piszesz na klawiaturze, to stosowanie dużych liter i stylu wielbłądziego tylko w małym stopniu zwiększa czas pisania.


© Helion 2003. Autor: Adam Boduch. Zabrania się rozpowszechniania tego tekstu bez zgody autora.

2 komentarze

Jojersztajner 2006-12-11 13:53

Gdy wysłałem ten artykuł z poprawionym Unikodem, zdałem sobie sprawę, że większość (jeśli nie wszystkie) rozdziałów zawiera sporo znaków Unikodu, chociażby —, ” i „. Znaki Unicode umieszczałem również ja w swoich postach, komentarzach i zgłoszeniach na <url=http://4programmers.net/coyote/bug.php>usterkowni</url>. Pomyślałem sobie, czy nie można by pogrzebać w zrzucie stanu bazy sprzed zmiany serwera na ten i załadować to, co pisane Unikodem ponownie?