Delphi - Jak pisać?
Mon, 10 March 2003
Wstęp
Jeśli udostępniasz źródło swojego programu (np. OpenSource), mile widziany jest przejrzysty kod. Długie procedury zacznij dzielić na kawałki odpowiadające poszczególnym, mniejszym zadaniom. Kod źródłowy formatuj używając wcięć typu:
procedure TMainForm.Liczby(zmienna: byte);
begin
If zmienna = 3 Then
ShowMessage('3');
If zmienna = 4 Then
Begin
If CheckBox1.Checked Then
zmienna := zmienna + 3;
ShowMessage('4');
end;
end;
Takie ułożenie linii jest bardzo mile widziane. Jak pewnie zauważyłeś w ten sposób napisane instrukcje wyraźnie podkreślają operacje podrzędne (tak je nazwałem), np. spełniane dopiero wtedy gdy spełniony zostanie warunek. Można to uściślić - im więcej spacji przed instrukcją, z tym bardziej podrzędnym działaniem mamy do czynienia. Dzięki temu, nie pogubisz się w przyszłości w swoim programie. A wierz lub nie, ale wystarczy jedynie kilka tygodni odejścia od projektu aby pozapominać niektóre rzeczy.
Drugim ważnym co do przejrzystości kodu elementem jest mus stosowania tzw. komentarzy. Komentarze to część kodu, która nie jest brana pod uwagę przez program kompilujący tzw. kompilator. W komentarzach, programiści umieszczają swoje uwagi, notatki, bądź w przypadku programów powstających na zasadach licencji "otwartej" swoje sugestie co do przyszłej poprawy wycinka kodu. Nie chodzi tu o prowadzenie forum na łamach kodu źródłowego, ale dodawanie swoich pomysłów, które nie bardzo wiemy jak przelać do kompilatora, a starannie obmyśliliśmy i zaplanowaliśmy ich działanie. W moim przypadku w komentarzach umieszczam wskazówki co do przyszłego, szybszego czytania kodu. Rozwiązanie to jest używane przez większość programistów. Komentarze mogą posłużyć nam jako nośniki starego, sprawdzonego kodu, przy testowaniu nowego. Zaznaczamy w nich również procedury co do których działania mamy pewne wątpliwości (bądź w ogóle nie spełniają one swojego zadania).
Poniżej przedstawię przykłady zastosowania komentarzy:
procedure TMainForm.Button2Click(Sender: TObject);
var
LosowaLiczba: byte; // zawiera wylosowaną liczbę
PoprzedniaLiczba: integer; // przechowuje poprzednio wylosowaną liczbę
label
skok; // etykieta skok;
begin
Randomize;
{ Tutaj następują czynnosci
wykonywane po wywołaniu
etykiety skok: }
skok:
LosowaLiczba := Random(7); // Losowanie liczby z zakresu od 0 do 6
If LosowaLiczba = 0 Then { Jesli wylosowana została liczba 0 to...
wylosuj jeszcze raz }
Goto skok;
Try // spróbuj (w wypadku gdy nie ma nic w kontrolce Memo2 zgłaszany jest błąd)
{ Przypisywanie do zmiennej 'PoprzedniaLiczba'
poprzedniej liczby ;) }
PoprzedniaLiczba := StrToInt(Memo2.Lines[Memo2.Lines.Count - 1]);
Except
{ Jesli kotrolka Memo2 jest pusta...
...to ... }
PoprzedniaLiczba := 0;
end;
{ Następuje dodanie do zmiennej 'PoprzedniaLiczba' liczby wylosowanej }
Memo2.Lines.Add(IntToStr(PoprzedniaLiczba + LosowaLiczba));
{ Jesli zmienna 'PoprzedniaLiczba' przekroczy wartosc 100...}
If PoprzedniaLiczba > 100 Then
{.. wyswietl komunikat z napisem 'Wygrał gracz po prawej' }
ShowMessage('Wygrał gracz po prawej');
end;
Jak widać może uprościć to nieco późniejsze czytanie kodu. Powracając do spraw 'organizacyjnych' dodam iż Delphi przyjmuje aż trzy sposoby na umieszczanie komentarzy:
umieszczane pomiędzy nawiasy klamrowe { }
Moim zdaniem jest to stosowany częściej od poniższego sposób umieszczania formularzy. Jest to komentarz wieloliniowy i należy go zamknąć za pomocą }, tak jak w poniższym przykładzie.{ to jest komentarz }
umieszczane pomiędzy nawias i gwiazdkę (* *)
Niewygodny - ale dla chcącego nic trudnego. Chodzi o to, że przy wstawianiu tego typu komentarza napracujecie się najbardziej ;) To także jest komentarz wieloliniowy i należy go zamknąć za pomocą *), tak jak w poniższym przykładzie.(* to również jest komentarz *)
pisane po dwóch slash'ach
Chyba najbardziej rozpowszechniony typ komentarza. Bardzo szybki i wygodny w użyciu. Nie trzeba go zamykać, ponieważ jest to typ jednoliniowy.// a to jest komentarz jednoliniowy
Kolejna wartą omówienia sprawą przy pisaniu programu jest fakt iż przypisując zmiennym wartości należy korzystać z poniższego schematu:
procedure TMainForm.JakasProcedura;
var
MojaZmienna : String;
begin
MojaZmienna := 'Jakiś tam tekst';
end;
Zwróćcie uwagę na odległości pomiędzy zmienną, a wartością do niej przypisywaną. Znak przypisania ma być od obu oddzielony spacją. To samo dotyczy znaków:
- porównania
- =
- >
- <
- <>
- >=
- <=
- znaku dwukropka
Następnym "punktem", którego należy się trzymać jest czytelne nazewnictwo zmiennych oraz zasada "Wielbłąda". Przy nadawaniu nazw zmiennym także należy trzymać się obowiązujących zasad. Nadajemy im nazwę nawiązującą do jej zadania w kodzie. Przy klasach, rekordach itp. stosujemy różne przedrostki mające później umożliwić nam ich rozpoznanie. Pewnie zastanawiacie się teraz na czym polega styl "Wielbłąda" - nic prostszego. Popatrz:
trudnojestprzeczytactekstpisanybezspacji
a teraz...
TrudnoJestPrzeczytacTekstPisanyBezSpacji
ten tekst przeczytać jest łatwiej :) Prawda, że banalne ?
Czego jeszcze należy się trzymać ?
To już chyba wszystko co najważniejsze. W zasadzie przy nazewnictwie komponentów przydałaby się jakaś rewolucja. Przyjemnie jest patrzeć na komponenty, które w swojej nazwie ukrywają przeznaczenie np. zamiast 'Button1' pisz: 'btnZamknij'. Formę główną zawsze należy nazywać po imieniu - 'MainForm'. To wszystko!
Dzięki wszystkim za uwagę i do zobaczenia!
Podobne artykuly:
- KillAd
- Delphi - Budowa modułu
- Delphi - Piszemy własny odtwarzacz multimedialny
- Delphi - Piszemy prosty edytor tekstu
- Delphi - Pobieranie plików z Internetu
- Delphi - Potęga możliwości ShellExecute()
- Delphi - Zasoby
Skomentuj
Komentarze czytelników
-
- kamil
- Sat, 11 September 2010, 0:15
- No cóż...
W niemal każdej książce traktującej o 'stylu' programowania można przeczytać, że komentarze powinny odpowiadać na pytanie 'dlaczego?' a nie 'co?', gdyż na to ostatnie pytanie doskonale odpowiada sam kod (o ile oczywiście jest porządnie napisany).
W tym świetle Twój przykład jest doskonałym przykładem niefrasobliwego, redundantnego 'przekomentowania'.
Styl taki nie dość, że w praktyce utrudnia czytanie, to jeszcze, z racji redundancji, może wprowadzić w błąd (pomyśl o sytuacji kiedy na skutek kolejnej edycji komentarz nagle mówi coś innego niż kod, któremu towarzyszy).