Użytkownik "fir" <p...@p...onet.pl> napisał w wiadomości grup
dyskusyjnych:5...@n...onet.pl
...
> dzieleni ich komentarzami na bloki czasem tak pisalem

I tak dochodzimy do wyższości Bożego Narodzenia nad Wielkanocą.

Przecież nikt nikomu nie każde pisać ciurkiem bez komentarzy. A to czy
podział będzie ujęty w same bloki klamerkami, czy jako oddzielne nazwane
procedury... to mało ważne.

Sens procedur (metod, jeżeli OOP) to budowanie kawałków kodu wykonujących
dobrze określone operacje na dostarczonych argumentach. Dlatego właśnie
podany przez ciebie przykład "wash-and-go" jest przykładem złego podejścia
do sprawy: wczytujesz bitmapę-robiszcośznią-iwypisujesz w jednej funkcji bez
podprocedur. A przecież bardziej naturalne byłoby mieć jedną procedurę do
wczytywania, drugą do robienia i trzecią do wypisywania. Potem skleić to w
całość w czwartej procedurze.

I oczywiście możliwe byłoby trywialnie prosto używanie np. innej
robiszcośznią. I parę innych rzeczy, np.:

int proc(char* nameIn,char* nameOut,int (*f)(char*))
{
BitmapType* bitmap;

int succed = 0;
if (readBitmap(nameIn,bitmap))
{
succed = f(bitmap) && writeBitmap(nameOut,bitmap);
free(bitmap);
}
return succed;
}

Oczywiście, nic nie stoi na przeszkodzie aby dać zmienną liczbę argumentów
itd. itp. - wtedy możesz łatwo zastosować kilka przekształceń itd. itp. - co
w wariancie "jedna duża procedura" - nie bardzo ci się uda. No chyba ze
obudujesz jakimiś switch-ami itd. itp. - ale wtedy będzie to już bardzo
bardzo nieczytelne.