> Owszem, robi sie metlik. Ale nie uparszcza sie go przez continue,
> return i break
Nieprawda, return i continue moze upraszczac zapis.
Przy zapisie z return i continue od razu wiem ze gdzies
na dole, pomiedzy zamykajacymi klamrami nie ma kodu ktory sie
moze wykonac. Lepiej widac do czego ten if sluzy.

A co z break nie wiem w tej chwili... chyba tez moze
upraszczac, czesto czytelniej jest wstawic w petle
kilka:
if( warunek1)
break;
if( warunek2 )
break;
niz kombinowac z jednym bardzo skomplikowanym wyrazeniem.

Zdarzaja sie takie duze procedury w programach ktorych
rozbicie na wiele malych nie zwieksza czytelnosci w
istotny sposob. Sam nie wiem dlaczego, moze dlatego ze
duza procedura wykonuje dobrze wydzielone zadanie? Mam
wiele takich procedur, w kazda procedure mam wbite rozne
testy i czuje ze jak rozbije ja na male procedury to strace
na czytelnosci.

Kiedy czytelnosc sie zwieksza? Gdy jest mniej kodu. W
moim przypadku nie bedzie mniej kodu, nie da sie
wydzielic wspolnego kodu w procedurach. Kiedy jeszcze
sie zwieksza czytelnosc? Gdy procedury pracuja na
swoich danych loklanych. Moje procedury testowe
prawie sa pozbawione lokalnych danych.

> tylko przez obiektowosc i zasosowanei odpowiednich
> wzrocow programowych. Nei tylko w trosce o czytelnosc, ale i
> elastycznosc. Oarz dekompozycje testow do zbioru obiektow
> odpowiedzalnych za testowanei okreslonych aspektiow.
Uzywanie hierarchii obiektow do sprawdzenia czy uzytkownik
moze wykonac jakas operacje jest troche jak uzywanie
armaty do zabicia komara. Nawet podzial na male funkcje
intuicyjne wydaje sie zly. Poza tym te procedury pare
razy mocno sie zmienily w trakcie rozwijania projektu.
Jakbym po kazdej zmianie mial sie zastanawiac nad doborem
optymalnej hierarchii obiektow to bym stracil kilka
dni czasu.

Nic mnie nie przekonuje, czasami duza procedura jest
jak najbardziej na miejscu.

Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl