Wstęp

Programowanie jest sztuką konstruktywną. W jaki sposób należy uczyć się konstruktywnej i twórczej działalności? Jedną z metod jest wyabstrahowanie na podstawie wielu przykładów, zespołu elementarnych zasad tworzenia i przekazanie ich w systematyczny sposób. Jednakże programowanie jest dziedziną wielce zróżnicowaną, często wymagającą złożonej działalności intelektualnej. Przypuszczenie, że kiedykolwiek można by jego naukę skondensować w postaci ścisłych recept wydaje się niesłuszne.
(Wirth, 1989)
Nie istnieją żadne absolutne reguły stylu programowania tak samo jak stylu pisania. ponieważ programowanie jest częściowo sztuką, a częściowo nauką.
(McCracken, Salmon, 1987)

Czym jest programowanie?

Programowaniem nazywamy ciąg wszystkich czynności związanych z rozwiązywaniem problemów przy użyciu komputera. Programowanie, wbrew częstej opinii, nie jest samym kodowaniem, a więc procesem pisania instrukcji w jakimś języku wyższego poziomu, zrozumiałym przez komputer. Kodowanie poprzedzone jest przez, ogromną często, ilość przygotowań. Są to:
  1. dokładne zdefiniowanie zadania
  2. wyjaśnianie i usunięcie nieokreśloności w sformułowaniu problemu
  3. wybór sposobu rozwiązania problemu
  4. naszkicowanie rozwiązania w zrozumiałym zapisie - schemat rozwiązania
  5. kodowanie (proces, tak naprawdę, mało twórczy) -' mechaniczny przekład rozwiązania problemu na poprawne gramatycznie zdania pewnego szczególnego języka (np. Pascala).
  6. wyłapanie i usunięcie błędów z napisanego programu - odpluskwianie
  7. napisanie i uzupełnienie dokumentacji programu
  8. dokładne sprawdzenie (wytestowanie) programu
Programowanie komputerów jest wyjątkowo złożonym zadaniem, przebiegającym w wielu oddzielnych fazach, z których każda jest tak samo ważna i każda w jednakowym stopniu przyczynia się do rozwiązania problemu

Faza definiowania problemu

Częsty błąd programistów polega na tym, że nie całkiem dokładnie definiują zadania programistyczne. Niejasności, które powstają w pierwszej fazie, fazie w formułowania problemu, przenoszą się na cały proces prac programistycznych.

Szkic rozwiązania

Z bardzo niewielkimi wyjątkami naprawdę prostych zadań programistycznych, program składa się najczęściej z wielu oddzielonych ale powiązanych ze sobę zadań. Przykładowo, program obsługi skomplikowanej listy płac może być zbudowany z wielu części, które kolejno sprawdzają dane, porządkują i łączą różnego rodzaju spisy, obliczają i drukują czeki płatnicze, drukują rapporty itp. Ważne jest by precyzyjnie określić zadania dla każdej z tych części programu oraz podać związki między tymi częściami. Zapewnia to, że wykonanie każdej z tych części z osobna doprowadzi do prawidłowo pracującej całości.

Wybór i reprezentacja algorytmu

Właśnie zostały określone różne zadania i podzadania potrzebne do rozwiązania problemu. Wiemy już jakie informacje muszą zostać dostarczone. Nie wiemy jednak jak program ma rozwiązać postawione zadanie. Algorytm jest szczególnym sposobem rozwiązania problemu. Może to byś sposób już znany, dostępny w literaturze, bibliotekach algorytmów lub algorytm opracowany przez programistę. Z pewnych powodów dobrze jest zapisać rozwiązanie w pewnym schemacie, a nie od razu w jakimś istniejącym języku programowania komputera. Jest to pośredni krok, któremu poświęcimy więcej czasu w póżniejszych częściach wykładu. Zapis schematyczny jest niezależny ani od typu komputera ani od jakiegokolwiek konkretnego języka programowania.

Kodowanie

Po bezbłędnym (prawie niemożliwe) sformułowaniu problemu, zorganizowaniu rozwiązania, naszkicowaniu krok po kroku co powinno być wykonane, można rozważyć rozpoczęcie procesu kodowania. Wybór języka programowania będzie prawdopodobnie zależał od następujących rzeczy: Niektóre języki programowania są językami bardziej uniwersalnymi, pewne z nich są zbudowane do bardziej specjalnych celów. Wiele języków jest szeroko dostępnych, ale niektóre mogą być dostępne tylko na pewnych typach komputerów.
Table 1: JĘZYKI PROGRAMOWANIA I ICH CECHY
FORTRAN 1957 num. mat., stat., fiz.
ALGOL 1960 num.
COBOL 1960 biznes
LISP 1961 listy, symb.
SNOBOL 1962 łańcuchy, edytory, bibl.
BASIC 1965 interaktywny, szkolny
PL1 1965 złożony, uniwers.
APL 1967 operatory
Pascal 1971 og., nauka prog.
ADA 1980 (1 )
Modula
C, C++ po 1972 og.
ASM zawsze szczeg.
Mathematica po 1959 mat., og., symb.
Maple
Macsyma M3!
HTML(?)
Perl
SQL

Faza sprawdzania - testowanie

Otrzymanie newet konkretnych wyników obliczeń nie kończy pracy. Musimy być ich pewni. Należy sprawdzić, że wyniki jakie daje nasz program są dobre w każdym wypadku, nawet takim, który nie był sprawdzony jawnie. Należe w tym celu wybrać takie dane, dla których potrafimy przewidzieć wyniki i dokonać wszelkich możliwych testów programu.

Dokumentacja

Proces dokumentowania programu jest zajęciem ciągłym. Dokumentację programu tworzą wszystkie materiały z etapów poprzednich, a więc Dokumentacja powinna zawierać zarówno informacje dla użytkownika jak i dla programistów, którzy ewentualnie w przyszłości będą dokonywać zmian w kodzie programu (bywa tak, że jest ta sama osoba!).

Konserwacja i dostosowywanie

Program nie jest czymś stałym. Jest to narzędzie, które należy poprawiać (błędy w różnych fazach jego powstawania), dostosowywać do aktualnej sytuacji: różnice w konfiguracji sprzętu komputerowego, różne urządzenia wejścia-wyjścia, różnice w realizacji języków programowania dla różnych maszyn, itp. Starsze realizacje (wersje) programów, które są uaktualniane, należy uzupełnić o nowe informacje w ich dokumentacji. Każda interwencja w gotowy program powinna zakończyć się dokładną informacją na ten temat. Tylko dobrze zorganizowane programy, z przejrzystą o nich dokumentacją, mają szanse na przetrwanie.

Podsumowanie

Z tego co zostało powiedziane wynika, że programowanie nie jest prostym, liniowym procesem w wyniku którego zawsze powstaje dobry program. Wiele kroków podczas jego realizacji pokrywa się, inne są ciągle powtarzane. Przykładem może być proces odpluskwiania czyli proces wychwytywania i usuwania wszelkiego typu błędów, które zostały popełnione na różnych etapach programowania (po angielsku debuging), proces poprawiania dokumentacji, itp. Szybko można nauczyć się kodowania, czyli przepisywania programu w języku zrozumiałym dla komputera, ale być dobrym programistą oznacza o wiele więcej. Jest to bowiem zrozumienie i stosowanie reguł z całego widma zagadnień związanych z programowaniem. Wymaga to aktywnej nauki i długiej, często wieloletniej, praktyki.

Czas

Można w przybliżeniu podać przybliżony czas (w procentach) potrzebny na wykonanie poszczególnych kroków, opisanych wyżej. Powyższe dane zostały zaczerpnięte z książki McCrackena i Salmona. Proszę zwrócić uwagę jak mało czasu poświęca się średnio na samo kodowanie, a więc na to co błędnie interpretujemy często jako programowanie.

Co jest ważne w procesie programowania?

Charakterystyka dobrych programów

Oto kilka cech uważanych za takie, które charakteryzują dobry program.

Styl programowania

Rozdział ten wymaga znajomości procesu programowania jak też znajomości języka wyższego poziomu i może być opuszczony przy pierwszym czytaniu. Rozważania są oparte na pracy McCrackena i Salmona z 1987 roku. Styl programowania jest często indywidualną sprawą programisty, ale powinien też spełniać pewne reguły ogóle. Dotyczą one następujących spraw. Postaram się kolejno omówić zasygnalizowane problemy. Nazwy zmiennych w programie. Dobrze jest stosować rzeczowniki dla oznaczania nazw wszelkich danych, czasowniki dla funkcji i procedur (rozkazy, np. dziel, dodaj itp), przymiotniki dla zmiennych logicznych (w Pascalu boolean). Jednolite nazwy są mało czytelne. Najlepiej jest używać nazw, które coś oznaczają, powiadamiając tym samym użytkownika (intencjonalnie) o możliwościach funkcji czy procedury, czy też wskazując sens zmiennych, itd. Nazwy bardzo długie, chociaż mogą być komunikatywne, są mało praktyczne jeśli nie stosujemy wyróżnień takich jak duże litery czy podkreślenie (underscore) np. nazwa dodajdwieliczby jest mniej czytelna od nazwy DodajDwieLiczby lub od nazwy dodaj_dwie_liczby. Wielkości stałe. Z wyjątkiem zera, jedynki i może jeszcze kilku innych stałych, nie należy wprost używać stałych w całej treści programu, w jego wnętrzu. Najlepiej zadeklarować (zgłosić) je w części opisowej, specjalnie do tego przeznaczonej, np. za pomocą słowa Pascala const. Zmiana sprzętu często powoduje idące za nią zmiany przybliżonych wartości różnych stałych. Ile czasu zmarnujemy wyszukując w programie miejsca, w których występuje stała π zapisana jako liczba zmiennoprzecinkowa z dokładnością do 9 miejsc znaczących by zamienić ją na liczbę o 12 miejscach znaczących. Nie używajmy gołych stałych! Powiedzmy, że w programie używamy tablicy, której rozmiar 100 zgłosiliśmy kilkakrotnie pisząc między innymi ciąg znaków [1..100]. Załóżmy, że zmienimy wymiar 100 wszędzie, automatycznie, za pomocą edytora tekstu, na 200, a przy okazji, całkiem nieświadomie, zamienimy temperaturę jakiegoś procesu też na 200, ale stopni. Co się wtedy stanie? Liczba zmiennych globalnych. Należy minimalizować liczbę zmiennych globalnych, dostępnych z całego programu. Zmiany w procedurach czy funkcjach, których jest wiele w programach, są zmianami lokalnymi. Często zapominamy przy nich o zmiennych globalnych. W ten sposób łatwo o błędy. Deklaracje typów zmiennych. Wszystko, co tylko się da, należy umieszczać w deklaracjach type, włączając w to podzakresy, definicje tablic oraz rekordów. Odstępy, puste linie, akapity. Należy używać odstępów, pustych linii i akapitów. Puste linie (jedna, dwie) POWINNY! oddzielać różne fragmenty programu i podprogramy. Akapitów używamy w instrukcjach złożonych. Należy do dobrego tonu podpatrzenie jak radzą sobie z tym inni. Decydując się na jakiś styl trzymajmy się go zawsze. Nie mieszajmy różnych stylów. Programy tracą wtedy na czytelności. Z czasem praktyka pokaże, że trzymanie się jednego stylu opłaca się. Tymczasem należy się do tego przyzwyczajać. Inteligentne komentarze. Nie należy pisać komentarzy w miejscach, które są oczywiste i jasne. Przesadne używanie komentarzy może oznaczać, że programista nie bardzo wiedział co czyni. Np. komentarz {Tutaj pod zmienną x podstawiamy 7 }, uczyniony w miejscu x:=7 jest niepoprawne. Podział na sekcje, podprogramy. Program zbudowany jest z części: funkcje i procedury, z których każda ma konkretne zadanie. Zadanie dzielimy na kawałki i następnie proste, zrozumiałe części programu łączymy razem. Jest to realizacja zasady dziel i rządź. Proces ten zwie się też modularyzacją (część to moduł). Należy zadbać o spójność modułów. McCracken i Salmon piszą, że jeśli uda się znaleźć słowo określające to co robi dany moduł, to właśnie ten fakt oznacza, że funkcja ta jest spójna, koherentna. Drugą cechą modularyzacji jest przejrzystość komunikacji (lub transmisji). Polega to na tym, że moduły mogą w prosty sposób komunikować się między sobą, używając przy tym minimalnej liczby zmiennych globalnych.



Powtórzmy.
There is no absolute rules of programming stylej any more than there can be absolute rules of style for any other kind of writing, since programming is partly an art and partly a science
(McCracken, Salmon, 1987)

Footnotes:

1Nazwa pochodzi od imienia Ady Lovelace z domu Byron, bliskiej przykaciółki i współpracownika Babbagge'a, projektanta maszyn liczących i prekursora budowniczych dzisiejszych komputerów.
File translated from TEX by TTH, version 4.03.
On 16 Oct 2013, 21:50.