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

Prefiks	Zmienna
i	Integer
i	Cardinal
i	Longint
w	Word
dw	DWORD
s, str	String
c, ch	Char
pc	PChar
b	Boolean

Tabela A.2. Prefiksy popularnych komponentów

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.