artykuły

Delphi - Jak pisać?

19:20
pon, 10 marzec 2003
Artykuł zwraca uwagę na dość często pomijaną w programowaniu zasadę - zasadę pisania czytelnego kodu. Objaśnia co robić, by kod był czytelny nie tylko dla osoby która go napisała (kiedy spojrzy na niego po paru miesiącach), ale również dla innych osób. Tekst opisuje dobre nawyki, które warto sobie wyrobić, chcąc by nasz kod wyglądał elegancko i schludnie.

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 jednoliniowyKolejna 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!

12345
Delphi - Jak pisać? Autor opinii: Czytelnicy, data przesłania: 5

Podobne artykuly:

Skomentuj

Aby zamieścić komentarz, proszę włączyć JavaScript - niestety roboty spamujące dają mi niezmiernie popalić.






Komentarze czytelników

    • kamil
    • sob, 11 wrzesień 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).
Dexter