> On Sat, 06 Aug 2011 22:13:47 +0200, m...@t...pl wrote:

> W dalszym ciagu nie rozumiem co wielowatkowosc ma do rzeczy
Przeciez to proste, nie trzeba wykonywac testow zwiazanych z
synchronizacja watkow, program bez watkow jest prostszy, mniejszy,
mniej trzeba sie w nim troszczyc o estetyke kodu. A moze to
juz chodzi o cos wiecej niz estetyke i styl, moze chodzi o
jakas "systematycznosc".

> Jezeli klamra otwiera sie w linii 100 a zamyka w linii 1000, to
> jedynym sensownym rozwiazaniem jest wyrzucenie programisty z pracy.
> Najlepiej z wilczym biletem.
Ja raczej bym wyrzucal gdy przestali myslec a zaczeli stosowac
jakies "twarde zasady".

> Ja przypomne czasy gdy na pl.comp.objects toczyly sie zazarte
> dyskusje, miedzy innymi o stylu programowania. Z owych czasow, zapewne
> przedpotopowych z punktu widzenia mlodych "miszczow" programowania
> pochodzi zasada: jak metoda nie miesci sie w calosci na ekranie, to
> prawdopodobnie cos spieprzyles z projektem.
Zgadza sie, to oznacza ze prawdopodobnie cos zostalo
spieprzone. Ale projekt o ktorym mowie jest bardzo
staranny. Programowanie to nie matematyka, ze jesli
2 + 2 = 5 to cos na pewno zostalo spieprzone.

Nie zawsze jest wyrazna korzysc z rozbicia jednej
duzej procedury na 20 malych procedur. W duzej
ilosci malych procedur czasami tez mozna odczuc
wrazenie metliku.

Duza procedura o ktorej mowie jest polimorficzna w
wielu klasach. Projekt zostal tak skonstruowany ze
rozszerzenie funkcjonalnosci dodaje sie poprzez
tego typu klase (wyprowadzona z bazowej). Przed
wykonywaniem wlasciwych operacji na danych nastepuje
szereg testow. Testy sa podzielone na kilka logicznych
etapow, ale pomimo to, jeden z etapow testowania bywa
orgomy. Procedury testujace tylko odczytuja dane,
wiec niebezpieczenstwo bledu jest znikome. Procedury
testowe niemal nie pracuja na swoich lokalnych danych,
dane testowe sa przygotowywane przez inne procedury.
Nie ma mowy o zadnym partactwie w projekcie, projekt
jest... okreslilbym wlasnie "systematyczny". Np. w
przypadku wykrycia usterki od razu z duzym
prawdopodobienstwem wiadomo w ktorym pliku sie
ona znajduje i w ktorej procedurze.

Mniej/wiecej mam taki kod:
pusty wiersz
pusty wiersz
/********************************/
/* Komentarz */
tmp = odczyt_danych_1();
if( ! tmp.test_a() ) {
cofniecie transkacji
logowanie bledow
return kod_bledu;
}
/*********************************/

Oczywiscie czasami jest bardziej skomplikowany, ale
najwazniejsze jest to, ze dane loklane sa mocno ograniczone i
jeden test ma praktycznie zerowa mozliwosc wplywu na drugi.
Na 1-2tys linii kodu sa 2-3 zmienne lokalne.

A zreszta po podziele co zrobic? Moze tak:
LacznyTest() {
if( Test1() ) {
if( Test2() ) {
if( Test3() ) {
.............
return 0;
} else
return kod_bledu_N;
} else
return kod_bledu_N-1;
}
...................
} else
return kod_bledu_1;
}
przeciez to jest nadal bagno, trzeba cudu zeby w tych
klamerkach sie nie pogubic. Kluczowe dla czytelnosci
jest:
if( warunek )
akcja();

a nie:

if( warunek )
duzy odstep
akcja();

Od razu widac jaki warunek jest zwiazayn z jaka akcja.

Analogicznie w duzych petlach:
for( ... ) {
if( ) {
if( ) {
if( ) {
}
}
}
}

Przy duzej ilosci if-ow robi sie metlik. Jesli tylko mozna,
to nalezy uproscic przez continue. contiune i return upraszcza,
bo od razu widac ze gdzies pomiedzy zamykajacymi klamerkami
nie ma kodu ktory sie moze wykonac gdy warunek jest nieprawdziwy.
Podczas myslenia nad znaczeniem warunku od razu odrzucamy
czesc kodu petli, albo czesc kodu procedury - jest prosciej,
mamy mniej aspektow do przeanalizowania.


> Zreszta, zalecenei jest aktualne do dzis. Proponuje mala ksiazeczke
> "The Elements of Java Style", Vermuelen i inni, paragraf 69: Define
> small classes and small methods.
> O ile mi wiadomo, ksiazeczka byla wydana po polsku
Dobrze znam ta zasade, jesli widze w danym zastosowaniu
plynace z niej korzysci to ja stosuje. Ba, nawet jesli
nie widze korzysci to ja czesto stosuje - bo bardzo lubie.
Jednak jesli korzysci sa znikome, albo dyskusyjne i jej nie
zastosuje to potem nie cierpie w zaden sposob z powodu
jej braku w projekcie.

Pozdrawiam

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