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

Czasami to jest racja a czasami bez sensu. Czesto czuje duzy
komfort jesli ciag instrukcji ktorego dotyczy if jest krotki, w
szczegolnosci gdy sprowadza sie do jednej instrukcji return.
Jesli mamy:
if( warunek ) {
instrukcje;
}
to oczy zwyczajnie sie mecza przy w wyszukiwaniu klamry
zamykajacej. Nawet gdy procedura ma 20-30 wierszy to
jest meczace.

W takim kodzie:
if( ! warunek )
return;
instrukcje;
szybciej widze i rozumiem cale(!) przeznaczenie tego ifa.

Moze to zalecenie pochodzi z czasow gdy trzeba bylo zamykac
pliki, zwalniac pamiec, itd? Wtedy owszem w przy kilku
punktach wyjscia trudniej zapanowac nad zwalnianiem zasobow.
Dzis sa jezyki w ktorych pamiec i uchwyty plikow niewiele
mnie obchodza. A moze ten kto to zalecal mial wyjatkowy
dryg do liczenia klamerek? Ja takiego nie mam, myle sie i
mecze, musze korzystac z ulatwien.

> Don't use goto statements. If the target of a goto is not at the start
Instrukcja goto to jeszcze inna sprawa... srednio uzywam jej raz
na rok, nie wiem dlaczego... jak czuje ze trzeba uzyc goto to uzywam i
tyle.


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

No ale co z tego ze moge wydzielic z jednej procedury 10-30 blokow?
Na czytelnosci nie zyskam nic. Na bezpieczenstwie nic. Wydajnosci
nie potrzebuje. Co za roznica czy mam 30 funkcji czy jedna funkcje
z 30-ma blokami? Przypomne ze mowie o funkcji ktora nie ma nawet
jednej petli, nie wspominajac o danych lokalnych. Sterowanie leci z
gory do dolu, wykonywane sa kolejne testy, jak test nie przechodzi
to jest return. Sa przypadki gdzie podzial na 30 funkcji powoduje
tylko klopot - chocby wymyslenie sensowych nazw dla funkcji. No
chyba ze zrobie bez sensownych nazw, wtedy moze nie pomyle sie
przy kolejnosci wywolania, bo po numerkach latwiej poznac:

Funkcja1() {
}
Funckcja2() {
}
...............
FunkcjaN() {
}
Funkcja() {
if( ! Funkcja1() ) return 1;
if( ! Funkcja2() ) return 2;
if( ! FunkcjaN() ) return N;
}

Zysk z takiego czegos jest zerowy, taki sam zysk mam z dwoch wolnych
wierszy pomiedzy blokiem instrukcji.

Pozdrawiam


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