On Sun, 07 Aug 2011 12:03:56 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

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

Uczenie sie od "open source" to takjak wedle ludowego powiedzonka
"uczyl Marcin Marcina".

Jak uczyc sie od mistrzow, to raczej uczycsie od prawdziwych Mistrzow.
Polecam ksiazke "Software Tools", Kernighan i Plauger. Kod (kompletny
i dzialajacy) wielu UNIXowych utilities. Proponuje znalezc "goto". A
niektore z owych utilities calkiem skomplikowane: makrporocesor M4,
czy edytor ed.

Owzm, goto jest uzyteczna. Tak samo jak schodki w rakietach. Jak
mawial Osla Laczka, nauczyciel Pirxa: "schodki sa potrzebne dla
umierajacych atronautow"

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

Ksiazka jest dobra, ale jak na podrecznik stylu - za dluga. Ja bym
raczej polecal "Enough Rope to Shot Yourself in the Foot: Rules for C
and C++ Programming", Allen Holub.

http://www.holub.com/goodies/rules.html

Cytaty:

36 A subroutine should fit on a screen

54 A function should have only one exit point

No, chyba nikt nie nazwie Holuba "teoretykiem"...

http://www.holub.com/

A.L.

do góry

W dniu 2011-08-07 02:05, A.L. pisze:
[...]
>> 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?...

Pewnie znaczy to, że ktoś woli metodę szablonową tam, gdzie
sensowniejsza robi się strategia. Przy okazji ten ktoś nadal
używa dziedziczenia w roli kompozycji.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2011-08-07 00:49, Wojciech Muła pisze:
[...]
> 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.

Jak mi się takich warunków zaczyna mnożyć, to staram się zapisać
tablice Karnaugha. Zazwyczaj na tym etapie porządkuje mi się, co
tak naprawdę ten potencjalny gąszcz if'ów miał wyrażać i zostają
2-3 kolejne if'y z - o zgrozo! - więcej niż jednym punktem wyjścia
z funkcji.

--
Paweł Kierski
n...@p...net

do góry

On Sun, 07 Aug 2011 20:27:19 +0200, Pawe? Kierski <n...@p...net>
wrote:

>W dniu 2011-08-07 02:05, A.L. pisze:
>[...]
>>> 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?...
>
>Pewnie znaczy to, że ktoś woli metodę szablonową tam, gdzie
>sensowniejsza robi się strategia. Przy okazji ten ktoś nadal
>używa dziedziczenia w roli kompozycji.

Gratuluje przenikliwosci :) Ale mnie nie udalo sie tego wydedukowac...

A.L.

do góry

On Sun, 07 Aug 2011 11:51:19 -0500 A.L. <l...@a...com> wrote:

> On Sun, 07 Aug 2011 12:03:56 +0200, Wojciech Jaczewski
> <w...@o...pl> wrote:
>
> >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.
>
> Uczenie sie od "open source" to takjak wedle ludowego powiedzonka
> "uczyl Marcin Marcina".

Chyba, że to open source używany w przemyśle, np. PostgreSQL (i na
prawdziwie open sourcowej licencji). Bardzo przyzwoicie napisany,
ale goto znajdziesz w paru miejscach

> Jak uczyc sie od mistrzow, to raczej uczycsie od prawdziwych
> Mistrzow. Polecam ksiazke "Software Tools", Kernighan i Plauger.
> Kod (kompletny i dzialajacy) wielu UNIXowych utilities. Proponuje
> znalezc "goto". A niektore z owych utilities calkiem skomplikowane:
> makrporocesor M4, czy edytor ed.

Jest polska edycja, pt. "Narzędzia programistyczne w Pascalu". Czytałem
większe fragmenty i uważam, że to powinna być lektura obowiązkowa na
pierwszym roku studiów. Nie mówiąc, że bardziej wciąga niż niejedna
powieść. :)

> Owzm, goto jest uzyteczna. Tak samo jak schodki w rakietach. Jak
> mawial Osla Laczka, nauczyciel Pirxa: "schodki sa potrzebne dla
> umierajacych atronautow"

W praktyce goto ma zastosowanie do jednej rzeczy - zebranie w jednym
miejscu kodu, który zwalnia pamięć, zamyka pliki itd. Używałem w C,
w modułach dla Pythona. Inaczej nie szło tego napisać, bo kod by się
powielał n razy, co wg mnie było zupełnie niepotrzebnie i dawało okazję
do większej liczby błędów.

w.

do góry

On Sun, 7 Aug 2011 21:07:12 +0200, Wojciech Mu?a
<w...@p...null.onet.pl.invalid> wrote:

>On Sun, 07 Aug 2011 11:51:19 -0500 A.L. <l...@a...com> wrote:
>
>
>
>> Jak uczyc sie od mistrzow, to raczej uczycsie od prawdziwych
>> Mistrzow. Polecam ksiazke "Software Tools", Kernighan i Plauger.
>> Kod (kompletny i dzialajacy) wielu UNIXowych utilities. Proponuje
>> znalezc "goto". A niektore z owych utilities calkiem skomplikowane:
>> makrporocesor M4, czy edytor ed.
>
>Jest polska edycja, pt. "Narzędzia programistyczne w Pascalu". Czytałem
>większe fragmenty i uważam, że to powinna być lektura obowiązkowa na
>pierwszym roku studiów. Nie mówiąc, że bardziej wciąga niż niejedna
>powieść. :)
>

Sa dwa wydanie: jedno (pierwsze) w C a drugie w Pascalu. Mialem na
mysli to pierwsze. Ale oba sa dobre.

>> Owzm, goto jest uzyteczna. Tak samo jak schodki w rakietach. Jak
>> mawial Osla Laczka, nauczyciel Pirxa: "schodki sa potrzebne dla
>> umierajacych atronautow"
>
>W praktyce goto ma zastosowanie do jednej rzeczy - zebranie w jednym
>miejscu kodu, który zwalnia pamięć, zamyka pliki itd. Używałem w C,
>w modułach dla Pythona. Inaczej nie szło tego napisać, bo kod by się
>powielał n razy, co wg mnie było zupełnie niepotrzebnie i dawało okazję
>do większej liczby błędów.

Owszem. Jak Holub pisze: "there always are exceptions to rules"

A.L.

do góry

> 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

do góry

On Sun, 07 Aug 2011 23:22:48 +0200, m...@t...pl wrote:

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

Obawiam sie ze sie nie porozumiemy. Dobrze ze nie pracujemy razem.

A.L.

do góry

> On Sun, 07 Aug 2011 23:22:48 +0200, m...@t...pl wrote:
> >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?
> Obawiam sie ze sie nie porozumiemy. Dobrze ze nie pracujemy razem.
Tym sposobem wkradl sie aspekt pracy. Otoz to co sie robi w pracy
czesto w jakims stopniu odbiega od wlasnych pogladow. Jak ktos
chce zebym napisal cos w okreslonym stylu i za to placi, to przeciez
nie powiem mu ze nie napisze. Nawet jak ktos nie narzuca stylu
programowania, a np. kolega z pracy powie mi: napisz w taki i taki
sposob bo tak lubie, to nie bede sie szczegolnie buntowal.

Ostatnio mialem specyficznego klienta, osoba prawdopodobnie
poczatkujaca w C/C++, a chcial aplikacje z kodem zrodlowym.
Otrzymalem takie wytyczne, cytuje: "napisz to tak, zeby glowna
struktura danych byla w postaci zmiennych globalnych, bo tak
bedzie latwiej". Nie mam bladego pojecia co bedzie latwiejsze
gdy glowna struktura bedzie dostepna globalnie, czyli dostepna bedzie
dla wszystkich metod w programie. On chcial, a ja pokornie zrobilem,
bylo troche trudnej, ale to nie ja placilem za sposob wykonania.

Ja gleboko ubolewam ze nie pracujemy razem Panie Andrzeju.
Jakbym np. przy uzyciu jakiegos narzedzia wysiwyg wygenerowal
fragment interfejsu grficznego np. w xmlu, a potem kierownik
projektu by mi powiedzial: "teraz nie kopiuj tego do jednego stringa,
ale dobrze zastanow sie jakie tam sa logiczne czesci i podziel to na
50 procedur, tak zeby w kazdej bylo gora 20 wierszy, a my ci
potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
byla by praca... tylko siedzenie i ciecie banalnego kodu
na procedury... Czasami jestem bardzo zmeczony z powodu
presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
ze nie pracujemy razem.

Pozdrawiam

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

do góry

On Mon, 08 Aug 2011 10:03:32 +0200, m...@t...pl wrote:

>potem i tak dobrze zaplacimy za kazda godzine pracy..." Piekna to
>byla by praca... tylko siedzenie i ciecie banalnego kodu
>na procedury... Czasami jestem bardzo zmeczony z powodu
>presji na efektywnosc czasowa... Chcialbym tak sobie siedziec i
>przez 90% czasu ciac na male fragmenty i dobrze zarabiac, tak
>dobrze jak zarabiaja w Ameryce, naprawde bardzo ubolewam
>ze nie pracujemy razem.

Niestety, nawet w Ameryce praca nie sprowadza sie do ciecia kodu. Ale
tu sie kodu nie "tnie". Tu sie projektuje porzadnie. Od samego
poczatku.

Ale ja bardzo przeparszam. Ja predzej uwierze ze w Smolensku byl
zamach niz ze:

a) procedura dluga na 1000 linii to jest porzadny projekt,
b) ze taka procedura jest czytelna i latwa do zrozumienia
c) Ze taka procedura jest latwa do testowania, modyfikacji i
utrzymania
d) ze soft zawierajacy taka procedure nie moze byc zaprojektowany
inaczej.

A.L.

do góry