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