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

>
>
>> A co ma wielowatkowosc do rzeczy? I co ma wydajnosc do rzeczy? I co ma
>> "zlosliwosc uzytkownika" do rzeczy?...
>Kod programu z wymienionymi przeze mnie cechami jest bardziej
>skomplikowany. Takie drobiazgi jak estetyka kodu w prostym
>programie sie nie licza, natomiast w duzym i skomplikowanym moga miec
>kluczowe znaczenie.
>

W dalszym ciagu nie rozumiem co wielowatkowosc ma do rzeczy

>> Pzrepraszam, ale to nonsens. Oryginalny Poster nic nie mowli o "kodach
>> bledu"
>A czy ja gdzies pisalem ze Oryginalny Poster cos mowil o kodach bledow?
>Padlo pytanie na temat:
>
>if(!warunek)
> return;
>kod();
>
>VS
>
>if( warunek ) {
> kod();
>}
>
>W malej procedurze nie ma najmniejszego znaczenia jaki styl wybierzemy.
>W duzej, jesli klamra otwiera sie w linii nr. 100, a zamyka w linii nr
>1000

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 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.

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

A.L.

do góry

On Thu, 4 Aug 2011 23:40:37 +0200 <g...@h...com> wrote:

> Witam,
>
> Czy taka konstrukcja narusza jakieś zasady/sty dobrego projektowania
> lub jeszcze innego wzorca projektowego? Chodzi mi o drabinkę if..else
>
> if (preserveR)
> {
> if (oldW >= oldH && !fit)
> {
> if (!onlyG || width < oldW)
> {
> newW = width;
> newH = (oldH * newW) / oldW;
> }
> }
> else if (!fit)
> {
> if (!onlyG || height < oldH)
> {
> newH = height;
> newW = (oldW * newH) / oldH;
> }
> }
> else
> {
> //...
> }
> }
> else
> {
> newW = width;
> newH = height;
> }

Hm, ja bym to raczej napisał tak:

if (preservedR) {
const bool sH = oldW >= oldH and not fit and (not onlyG or width < oldW);
const bool sW = not fit and (not onlyG or height < oldH);
if (sH) {
newW = width;
newH = (oldH * newW) / oldW;
}
else if (sW) {
newH = height;
newW = (oldW * newH) / oldH;
}
else
...
}
else
...


Kiedyś, przy bardziej "dzikiej" logice sterowania, gdzie warunków było
niewiele, jednak różnych kombinacji sporo, to najpierw kodowałem
każdy warunek na osobnym bicie, a później instrukcją switch
obsługiwałem kombinacje. W stosunku do wersji z if/else było 10x lepiej.

w.

do góry

> 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

do góry

On Sun, 07 Aug 2011 01:21:31 +0200, m...@t...pl wrote:

>> 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,

Jakich testow?...

>program bez watkow jest prostszy, mniejszy,

Mnei sie zawsze wydawalo ze jak sa swtki to jest bardziej
skomplikwoany


>mniej trzeba sie w nim troszczyc o estetyke kodu.

Niby dlaczego?...

> 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.

> Programowanie to nie matematyka, ze jesli
>2 + 2 = 5 to cos na pewno zostalo spieprzone.
>

Acha. Rozumiem. A czy 2 + 2 = 7 tez moze byc?...

>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).

A co to zanczy?...

> 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.

[..]

Dlatego powinien byc ustrukturalizowany a nie napisany jako jeden
"ciurek" kodu.

>Przy duzej ilosci if-ow robi sie metlik. Jesli tylko mozna,
>to nalezy uproscic przez continue. contiune i return upraszcza,

Owszem, robi sie metlik. Ale nie uparszcza sie go przez continue,
return i break, 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 aspektow.

A.L.

do góry

> 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

do góry

>

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

>

tak naprawde jak sie zastanowic to duze zaglebienia ifow
nie zdarzaja sie czesto - nawet 'if w ifie' to raczej ewenement,
musze kiedys zwrocic na to wiecej uwagi
(mozna by moze nawet powiedzec ze same ify zdarzaja sie srednio
czesto - w sensie ifow nie ma wcale az tak duzo )



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

do góry

> tak naprawde jak sie zastanowic to duze zaglebienia ifow
> nie zdarzaja sie czesto - nawet 'if w ifie' to raczej ewenement,

Jesli napiszemy tak:
if( warunek1 ) {
if( warunek2 ) {
if( warunek3 ) {
if( warunek4) {
if( warunek5 ) {
operacje_1();
}
}
operacje_2();
}
}
}

to zaglebienie ifow jest duze. Analiza po pierwszym spojrzeniu
na taki kod jest utrudniona - latwo pomylic sie w liczeniu
klamerek.


Jesli napiszemy tak:
if( !warunek1 ) return;
if( !waruenk2 ) return
// reszta kodu

to od razu mamy pewnosci ze warunek1 i warunek2 nie
ma nic wsplolnego z operacje_2(). Analiza
wersji z return jest prostsza.


> musze kiedys zwrocic na to wiecej uwagi
> (mozna by moze nawet powiedzec ze same ify zdarzaja sie srednio
> czesto - w sensie ifow nie ma wcale az tak duzo )
Wlasnie siedze nad takim projektem w ktorym ze wzgledu na
ogromna ilosc testow i ifow w "kazdej" klasie zostaly do
tego celu wydzielone 3 wirtualne metody. One niemal nic
innego nie robia tylko:

tmp = dane_tymczasowe()
if( ! jakis_test( tmp ) ) {
jakies_logi();
return kod_bledu;
}


Druga procedure na okolo 1-2tys wierszy mam taka:
a = dane_a1()
b = dane_b1()
p1 = funckcja_nieliniowa( a , b )

a = dane_a2()
b = dane_b2()
p2 = funckcja_nieliniowa( a , b )

..........................
return p1 * p2 * ... * pn;
Przy czym ponad 50% tego kodu to komentarze.

Nie da sie tego podzielic na male funkcje z wyraznymi
korzysciami.

Pozdrawiam


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

do góry

m...@t...pl wrote:

>> 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.

Czasami też upraszczać może użycie goto - chociaż zapewne wielu mędrców-
teoretyków powie że tego używać nie wolno, a zamiast tego trzeba zrobić kod
5 razy dłuższy, za to pozbawiony tego defektu. Ale jak przyjrzeć się
dostępnym dobrze działającym programom open-source, to w wielu z nich można
spotkać użycie technik, których ci mędrcy-teoretycy chętnie by zakazali.
Zarówno użycia goto, jak i bardzo długich funkcji.
Ponieważ A.L. często podaje tytuły do książek coś opisujących, ja odnośnie
używania długich funkcji sugeruję "The Art of Unix Programming". Niestety
nie podam konkretnie rozdziału, bo nie pamiętam. Można tam też przeczytać
coś o programowaniu obiektowym.

do góry

>

>

> > tak naprawde jak sie zastanowic to duze zaglebienia ifow

> > nie zdarzaja sie czesto - nawet 'if w ifie' to raczej ewenement,

>

> Jesli napiszemy tak:

> if( warunek1 ) {

>  if( warunek2 ) {

>     if( warunek3 ) {

>       if( warunek4) {

>         if( warunek5 ) {

>           operacje_1();

>         }

>       }

>       operacje_2();

>     }

>  }

> }

>

> to zaglebienie ifow jest duze. Analiza po pierwszym spojrzeniu

> na taki kod jest utrudniona - latwo pomylic sie w liczeniu

> klamerek.

>

>

> Jesli napiszemy tak:

> if( !warunek1 ) return;

> if( !waruenk2 ) return

> // reszta kodu

>

> to od razu mamy pewnosci ze warunek1 i warunek2 nie

> ma nic wsplolnego z operacje_2(). Analiza

> wersji z return jest prostsza.

>

>

> > musze kiedys zwrocic na to wiecej uwagi

> > (mozna by moze nawet powiedzec ze same ify zdarzaja sie srednio

> > czesto - w sensie ifow nie ma wcale az tak duzo )

> Wlasnie siedze nad takim projektem w ktorym ze wzgledu na

> ogromna ilosc testow i ifow w "kazdej" klasie zostaly do

> tego celu wydzielone 3 wirtualne metody. One niemal nic

> innego nie robia tylko:

>

> tmp = dane_tymczasowe()

> if( ! jakis_test( tmp ) ) {

>  jakies_logi();

>  return kod_bledu;

> }

>

>

> Druga procedure na okolo 1-2tys wierszy mam taka:

> a = dane_a1()

> b = dane_b1()

> p1 = funckcja_nieliniowa( a , b )

>

> a = dane_a2()

> b = dane_b2()

> p2 = funckcja_nieliniowa( a , b )

>

> ..........................

> return p1 * p2 * ... * pn;

> Przy czym ponad 50% tego kodu to komentarze.

>

> Nie da sie tego podzielic na male funkcje z wyraznymi

> korzysciami.

>

no ja powiedzialbym akurat raczej zgadzam sie z tym co ty tu
mowisz tak ze mnie nie musisz co do tego przekonywac -
zarazem nie pale sie zeby sie w to wglebiac bo tych spostrzezen
dokonalem sobie juz jakis czas temu;
choc mysle ze tez pare rzeczy o ifach mozna sobie jeszcze ustalic,
np przyjac robocza zasade by unikac czy przyjrzec sie przypadkow
'zagniezdzonych' ifow czy 'dlugich' ifow (jak mowie zdarza sie
to raczej rzadko) lub ifom wogole


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

do góry

On Sun, 07 Aug 2011 12:02:07 +0200, m...@t...pl wrote:

>
>
>> tak naprawde jak sie zastanowic to duze zaglebienia ifow
>> nie zdarzaja sie czesto - nawet 'if w ifie' to raczej ewenement,
>
>Jesli napiszemy tak:
>if( warunek1 ) {
> if( warunek2 ) {
> if( warunek3 ) {
> if( warunek4) {
> if( warunek5 ) {
> operacje_1();
> }
> }
> operacje_2();
> }
> }
>}
>
>to zaglebienie ifow jest duze. Analiza po pierwszym spojrzeniu
>na taki kod jest utrudniona - latwo pomylic sie w liczeniu
>klamerek.
>
>
>Jesli napiszemy tak:
>if( !warunek1 ) return;
>if( !waruenk2 ) return
>// reszta kodu
>
>to od razu mamy pewnosci ze warunek1 i warunek2 nie
>ma nic wsplolnego z operacje_2(). Analiza
>wersji z return jest prostsza.
>
>
>> musze kiedys zwrocic na to wiecej uwagi
>> (mozna by moze nawet powiedzec ze same ify zdarzaja sie srednio
>> czesto - w sensie ifow nie ma wcale az tak duzo )
>Wlasnie siedze nad takim projektem w ktorym ze wzgledu na
>ogromna ilosc testow i ifow w "kazdej" klasie zostaly do
>tego celu wydzielone 3 wirtualne metody. One niemal nic
>innego nie robia tylko:
>
>tmp = dane_tymczasowe()
>if( ! jakis_test( tmp ) ) {
> jakies_logi();
> return kod_bledu;
>}
>
>
>Druga procedure na okolo 1-2tys wierszy mam taka:
>a = dane_a1()
>b = dane_b1()
>p1 = funckcja_nieliniowa( a , b )
>
>a = dane_a2()
>b = dane_b2()
>p2 = funckcja_nieliniowa( a , b )
>
>..........................
>return p1 * p2 * ... * pn;
>Przy czym ponad 50% tego kodu to komentarze.
>
>Nie da sie tego podzielic na male funkcje z wyraznymi
>korzysciami.
>
>Pozdrawiam


Cytat 1

Single Entry Point, Single Exit Point Style

A piece of code is likely to be more easily understood if it has only
one entry point (at the top of its listing) and only one exit point at
(or near, e.g., a return statement just before the closing "}" of a
non-void C++ function) the bottom of its listing. In C++, this
philosophy has the following implications:

Don't use goto statements. If the target of a goto is not at the start
of its block, then its block has two entry points; if the goto
statement is not at the end of its block, then its block has two exit
points. The goto statement can also have other undersirable effects on
the understanding of the listing; for example, see the Loop Style
section.
Don't use exit statements. Since a typical C++ program ends at a
return 0; statement at the end of its main function, the use of an
exit statement provides a second exit point from the program.
Don't use break statements except to end a case of a switch structure.
To use a break, say, to exit a loop, provides the loop with a second
exit point.
Some argue for exceptions to the rules stated above in order to
simplify the flow of control amidst complex code. For example, some
argue that if main calls on blah, which calls on ..., which calls on
gallumph, and an unusual error is detected by the code of the latter
function that makes further processing within the program pointless,
it is easier for the programmer to use an exit statement to end the
run of the program than to provide appropriate if statements, one in
each of the chain of functions alluded to above, to provide "normal"
exit from the main function's end-of-listing or return 0; statement.
Since student exercises rarely get complex enough to make a strong
argument along these lines, I prefer my students to follow the
guidelines above.

Cytat 2

Length of a Subprogram

KISS - Keep it short, smarty! (You thought I would use "stupid"?
Stupid people don't write software.)

In general, it's wise to keep every subprogram (in C++, every
function, including main) short. A reader typically tries to
understand one function at a time, so keeping functions short makes
them more "digestable." A classical guideline: a maximum of 25 lines
of code, what used to be the maximum viewable on a computer screen
using a typical text editor. Today's screens often show more than 25
lines, and I won't send a student to the guillotine for a 26th line,
but if you're in excess of 30, there's probably a natural way to
abbreviate your function, perhaps by extracting one or more blocks of
its code as (a) separate function(s).

http://purple.niagara.edu/boxer/essays/prog/style.ht
m#toc

Cytat 3:

Rule of Parsimony: Write large program only if it is demonstrated that
nothing else will do

Teh Art of UNIX Programming, strona 40

Ja mam wrazenie neijakie ze 20 lat programowania strukturalnego (1965
- 185) i prawie 30 lat obiektowego (1985 - do dzis) jakos wyparowaly.
A moze tego nie ucza dzisiaj?... I prowracamy do programowanie w
COBOLU? Programwoania w OBOLU przy pomocy Javy?...

do góry