Zasady dobrego programowania

0

Czy slyszal ktos o takich zasadach, ktore mowia o tym, ze programista powinien unikac wywolywania break w petli, podobnie jak instrukcji goto w ogole? Albo ze nie powinno sie w funkcji wielokrotnie uzywac return()? Ciekawi mnie takie podejscie, czym ono jest uargumentowane?

0

Tak samo jak czytałem kursy C++ i o pętli for przeczytałem że bardzo niemile widziane jest jak ktoś w trakcie pętli modyfikuje zmienną strującą...

Myśle ze jest to uargumentowane tym że mając te wszystkie wymienione nawyki łatwo zrobić błąd w programie (przewidziec jak sie zachowa w zależności od tego co zrobi użytkownik), albo pogubić się we własnym kodzie... pamiętam jak trudno było napisać coś większego w czystym basicu za pomocą GOTO i GOSUB... w takich programach po pewnym czasie samemu sie nie wie o co chodzi :P

0

Akurat ze zmienianiem zmiennej sterujacej to sie zgadzam, bo rzeczywiscie moze to spowodowac blad. Ale break w srodku petli? Chyba nie bardzo. Nie wiem.

0

Więc wszyscy programiści systemowi muszą łamać zasady dobrego pisania, nie widzę innej mozliwości, bo pisanie osów wiąże się ze stworzeniem jak najwydajniejszego kodu w jak najmniejszej obietości :D

Druga rzecz, że tego rodzaju zasady dotyczą bardziej programowania grupowego, programów open source i wszelkich innych sytuacji kiedy źródło jest ogólnie dostepne.

Tertio: goto/break/continue nie powinny wystepować w normalnym kodzie, w większości wypadków da się albo zmienić pętle z for na repeat-until, czy while tak aby można było dopisać odpowiedni warunek (w c i for mogą być dowolne warunki, więc rodzaj pętli nie ma znaczenia)

audi quattro: obsługa błedów, blędy i/o i przydziału pamięci to najczęstsze błedy (właściwie jedyne, których nie można przewidzieć, to tylko błędy i/o) i w takich sytuacjach sam bardzo chętnie uzywam wszelkich brudnych chwytów, byleby nie wywalił sie program i nie widzę w tym nic złego, a wrecz przeciwnie, jeden skok na koniec funkcji, czy return/exit przed czasem mogą uratowac sytuacje.

Ale to czy w źródle bedą umieszczane elementy języka, ktore niektórzy puryści mogą uznać za złamanie jakichś wydumanych zasad, jest mało ważne, to nadal są to elementy języka. Duzo ważniejsze jest aby samo źródło było napisane w sposób czytelny i konsekwentny. Nie ważne, czy wcięcia będą na 1, 2 czy n spacji, ważne, żeby były w całym programie jednakowe. :D

0

Te akurat zasady, ktore wymieniles, to proba przeforsowania programowania strukturalnego. Chodzi o to, ze programujac strukturalnie sa mniejsze szanse na popelnienie bledu niz niestrukturalnie. Ale tak jak flabra napisal... piszac cos, gdzie szybkosc dzialania jest podstawa, olewaj wszystki zasady jakie ci przeszkadzaja, oby tylko wykrzesac te dodatkowe, brakujace takty.

Natomiast wiele jest zasad, ktore nie sa zwiazane juz z wojna strukturalne <-> niestrukturalne. Ja ostatnio nacialem sie na warunki w C:
if (a == 0)
if (0 == a)
Niestety piszac w zespole, koniecznie trzeba na to uwazac... (kumpel napisal if (a = 0) i pare godzin przesiedzielismy, zanim znalezlismy blad ;( )

0

Ja generalnie staram się trzymać tych zasad (no chyba że są tak bzdurne jak "NIE UŻYWAĆ BREAK W ŚRODKU PĘTLI"), to to bardzo pomaga. Całkowicie zgadzam się, że programiści OS'ów muszą łamać te zasady. Ale nie tylko oni, bardzo często zdarza się że te zasady po prostu TRZEBA nagiąć lub złamać. Ale chyba przyznacie, że używanie GOTO w PASCALu jest bezsensowne, skoro o wiele łatwiej można użyć procedur i funkcji. Za to pisząc skrypty w BATCHU, instrukcja GOTO jest jedynym sensownym rozwiązaniem.

Bardzo śmieszy mnie postawa Borland'a. Kiedyś, gdy jedni z ich programistów poczytali sobie jakiś skrypt Microsoftu (ciekawe, skąd go wzięli :> ) i powiedzieli: "Czytając ten skrypt natrafiliśmy na całą masę instrukcji całkowicie sprzecznych z zasadami dobrego programowania". Przecież to jest zupełnie śmieszne.

0

Generalnie, staram się trzymać takich zasad. Nie pamiętam kiedy ostatnio użyłem w Pascalu/Delphi/Lazarusie break czy czegoś takiego. Zazwyczaj to omijam. O goto nie wspominając. Ale niech ktoś spróbuje napisać jakiś rozsądny programik w <ort>Assamblerze </ort>bez goto :] Przy tym skrypty basha to pestka ;> Wiele z nich można zrobić inaczej, bo jest wiele ciekawych funkcyjek i możliwości (warunkowe wykonanie bloku informacji chociażby, lecz nie jestem pewny, czy w DOSie również...). A w ASM'ie to problem. Ale tak czy inaczej w Pascalu/Delphi/Lazarusie i C/C++/VC itp polecałbym stosowanie się tych zasad, jeśli tylko program ma być czytelny. Jeśli jednak bardziej liczy się optymalizacja szybkości i zajętości pamięci, to nie ma sensu na to zwracać uwagi.

0

wywolywania break w petli

he he, akurat dzisiaj wymyśliłem sobie procedurke, w której break ratuje mi życie, a tu takie zasady no nie ładnie :D

0

Nie podawajcie za przykład assemblera, basica i itp. bo to inna para kaloszy :P

0

nie rozumiem, czemu użycie break/continue miało by utrudniać zrozumienie kodu - raczej wręcz przeciwnie. pozwala łatwo rozbić warunki zakończenia pętli, przez co często na pierwszy rzut oka widać o co biega w pętli i kiedy ma się ona skończyć. poza tym czasami zdarza się, że nie da się nie użyć break (np.: sprawdzanie warunków wyjścia w dwóch kompletnie różnych miejscach zapętlonego kodu).
to samo się tyczy return - wg mnie kod z wieloma returnami jest łatwiejszy do zrozumienia, niż masa warunków i wcięcia kodu łącznie na kilkadziesiąt spacji.

0

Zgadzam się z LF`em .. sądze, że zasady te w obecnej formie są tylko "plotką". Zapewne kiedyś żył jakiś wybitny programista, któremu w owym czasie nie podobały się w/w metody programowania. Pewnie opublikował to gdzieś i trafiało to z ust do ust.. było rozpowszechnione na coraz to większych ilościach stron internetowych .. aż do dzisiaj pod nazwą " zasady dobrego programowania ". Zatem nie ma się czym przejmować - takie moje zdanie.

0

Dzieki za komentarze. Jestem tego samego zdania co LF... po prostu pewien wykladowca nakazuje trzymac sie takich zasad (typu nie uzywac instrukcji brak w petli, czy tylko jedno return w funkcji), o ktorych wczesniej nie slyszalem, i nie wiem czemu mialbym unikac takich konstrukcji.

0

Dokładnie. Wszystko jest narzędziem. Jedyny problem (lub "zasada dobrego programowania") brzmi: musisz umieć z tego rozsądnie korzystać.

0

Radzę powiedzieć temu wykładowcy, że plotek się da dużo nasłuchał, albo że jest starodawny.

0

Znam tylko jedną dziedzinę, gdzie nie wolno używać przerwań w pętlach. Dzielenie algorytmu na wiele procesorów - są metody optymaizacji, które wymagają ciągłych pętli aby stworzyć odpowiednie grafy etc. (właśnie piszę z tego projekt ;))

Może jeszcze gdzieś...

W pozostalych przypadkach nie widzę żadnych przeciwskazań.
Wolę mieć takie coś:
while (ab)
{if (x) break;
...
}

niż:
while (ab & ~x || qwe != 23) {...}

(taki tylko durny przykład)

0

Ale ta zasada dotycząca BREAK wywołała burzę... Ja też coś dorzucę jeszcze na ten temat...

Po to BREAK zostało wynalezione, żeby go używać, nie? A gdzie go można użyć, jak nie w pętli? <ort>przecieŻ </ort>BREAK właśnie do łamania pętli służy. Tak więc jest to w porównywalne ze stwierdzeniem: "W kamieniołomach nie wolno uzywać młotka do rozłupywania kamieni" :-/ .

0

Po to BREAK zostało wynalezione, żeby go używać, nie?

goto też 8-|

0

A gdzie go (break) można użyć, jak nie w pętli?

Należy użyć w switch() ;)

// wcale nie neguje uzycia jakiegokolwiek elementu jakiegokolwiek jezyka, tylko akurat pokazuje, ze break w c ma troszke wieksze mozliwosci

0

A w Adzie jest instrukcja "exit" do wyskakiwania z pętli i ma się dobrze, posiada nawet rozszerzenie które jeszcze sprawę ułatwia...

loop
   ...
   exit when X = 0;
   ...
end loop;

( Chociaż do teraz nie wiem czemu nie wprowadzono "return when" i "raise when" ).
Natomiast przypisywanie do zmiennej sterującej w pętli "for" jest jak najbardziej ble i co inteligentniejsze kompilatory tego zakazują. Taka praktyka wykracza poza semantykę fora i może powodować trudne do zdiagnozowania błędy.
A używanie "goto" tępił Dijkstra i tak się przyjęło, że jest złe. Oczywiście jest to instrukcja przydatna - między innymi wtedy gdy piszemy lub generujemy kod maszyny o skończonej liczbie stanów, ale może być niebezpieczna w co mniej inteligentych kompilatorach które pozwalają wskakiwać przez "goto" do wewnątrz innej jednostki (w przeciwieństwie do wyskakiwania).

0

A w Adzie jest instrukcja "exit" do wyskakiwania z pętli i ma się dobrze, posiada nawet rozszerzenie które jeszcze sprawę ułatwia...

Baa, nie wyobrażam sobie pisania bez exit! Taki kod byłby wolny i nieczytelny, exit rozjaśnia sytuację. Tak samo jest z return, choć to można już łatwiej ominąć. Ale skoro kompilator nie krzyczy z powodu wielu return w jednej procedurze lub funkcji to to chyba nie jest złe? Nawet ostrzeżenia nie pokazuje.

PS. Jeśli chodzi o tego borlanda i skrypt micro$hitu: rzeczywiście, nie wiem po co to stwierdzali, przecież chyba każdy wie jak beznadziejnie pisane są produkty tej firmy, tam raczej nikt nie przejmuje się by kod był czytelny i sprawnie działający(wydedukowane na podstawie ilości bugów w kodzie ;)).

PPS. Co do tego if (a = 0): tak to jest używać kompilatorów pokazujących "COŚ JEST ŹLE!" a nie co konkretnie jest źle. Albo "wszystko ok" ale w trakcie działania coś się wali (wiadomo o jaki język chodzi ;)). Jeszcze gorzej gdy dany język nie ma porządnego kompilatora bo jego budowa na to nie pozwala (znów wiadomo ;)).

0

Ja się przyznam że jeszcze NIGDY nie użyłem instrukcji break; i continue :] Zawsze da się rozwiązać problem bez ich użycia zachowując prostotę kodu, czytelność i szybkość, tylko trzeba trochę więcej czasu poświęcać. A co do GOTO to bosszzze kto by jeszcze tego używał no chyba że w asm :P

0

Ja się przyznam że jeszcze NIGDY nie użyłem instrukcji break; i continue :]

To chyba mało programowałeś...

Zawsze da się rozwiązać problem bez ich użycia zachowując prostotę kodu, czytelność i szybkość, tylko trzeba trochę więcej czasu poświęcać.

Nie wydaje mi się, żeby dało sie ZAWSZE przerobić kod na równie czytelny.

A co do GOTO to bosszzze kto by jeszcze tego używał no chyba że w asm :P

A co do goto, to gdzies mi sie kiedyś obiło uszy stwierdzenie że w Pascalu nie ma dobrego sposobu wyjscia z bloku begin..end i wtedy własnie własciwe i w pełni uzasadnione jest uzycie goto.

0

To chyba mało programowałeś...

Gwarantuje ci że mam obycie z programowaniem, bawię się w to prawie 5 lat, w tym 2,5 w asemblerze. Jak dalej nie wierzysz to sobie ściągnij engin.zip z działu download....

Nie wydaje mi się, żeby dało sie ZAWSZE przerobić kod na równie czytelny.

Ja tylko powiedziałem swoje zdanie, nie mam zamiaru się z tobą kłócić o to kto ma racje, bo to i tak nie ma sensu.....

0

Popieram Dominika (szczególnie w pierwszym punkcie).

A w poprzednim swoim poście zapomniałem o sprawie modyfikacji zmiennej iterowanej np. w pętli for. To akurat jest ogromna przewaga C nad Pascalem. Nie raz tego używałem sprawiając, że kod stawał się o wiele prostszy i zdecydowanie efektywniejszy. Nie będę przytaczał przykładów, bo nie staram się nikogo o tym przekonać - jednak ...naście lat programowania pozwala mi na zajęcie takiego stanowiska w tej dyspucie.

I jeszcze co do:

if (a=0) {}

Kompilator C++ podaje w tym przypadku warning "possibly incorect assigment" więc nie rozumiem, co w tym ostrzeżeniu jest nieczytelne.

0

Odkąd siedzę na tym forum zawsze spotykam się z waszą złośliwością.... jeśli ktoś nie postępuje jak wy od razu mieszany jest z błotem..... wielkie dzięki żegnam się z tym forum i tą stroną

//yy, jaką złośliwością? [green] - rzucasz focha jak 8 latek... bez komentarza - M

Fakt że reaguje trochę ostro ale jestem rozdrażniony, mam swoje powody...

// Marooned, bez komentarza to bez komentarza :> ADuch - to, że ktoś się z tobą nie zgadza, to nie znaczy, że trzeba sobie podciąć żyły, podpalić, wyskoczyć z okna i w trakcie spadania zastrzelić - ŁF

Dobra, dobra już mi lepiej :P.... można zamknąć temat :]

0

Gwarantuje ci że mam obycie z programowaniem, bawię się w to prawie 5 lat, w tym 2,5 w asemblerze. Jak dalej nie wierzysz to sobie ściągnij engin.zip z działu download....

Ależ ja absolutnie nie chce podważać twoich kompetencji w programowaniu. Ja aż takiego długiego stażu programistycznego nie mam, ale być moze po prostu zajmowaliśmy sie innymi dziedzinami programowania. Co do przydatności Break i Continue - przejrzyj sobie standardowe moduły w Delphi (bo o przydatności break w c++ chyba nie trzeba nikogo przekonywać), napisane jakby nie było przez zawodowych, profesjonalnych programistów, tworzących standardy stylu programowania - break i continue wystepują powszechnie, znalazłem nawet jedno goto :P .

0

Powiedzcie, co jest bardziej zrozumiałe:

for i := 0 to 35 do
 begin
   { instrukcje }
   if (warunek) then i := 35;
 end;

czy może:

for i := 0 to 35 do
 begin
   { instrukcje }
   if (warunek) then BREAK;
 end;

Ja uważam że raczej to drugie :D .

0

Powiedzcie, co jest bardziej zrozumiałe:

for i := 0 to 35 do
begin
{ instrukcje }
if (warunek) then i := 35;
end;

czy może:

for i := 0 to 35 do
begin
{ instrukcje }
if (warunek) then BREAK;
end;

A ja programuje (tylko!) od 2 lat .. i powiem tak: ciężko byłoby rozwiązać niektóre problemy bez Break / Continue. Bardzo często to wykorzystuje i chyba nie ma w tym nic złego :-/

btw: w 1-szym przykładzie powinno być: Integer(Pointer(@i)^); ;)

0

Powiedzcie, co jest bardziej zrozumiałe:

for i := 0 to 35 do
 begin
   { instrukcje }
   if (warunek) then i := 35;
 end;

czy może:

for i := 0 to 35 do
 begin
   { instrukcje }
   if (warunek) then BREAK;
 end;

Ja uważam że raczej to drugie :D .

Moze chodzi o to, ze jeszcze czytelniej (chyba) jest tak:

repeat
  {instrukcje}
  Inc(i);
until (i = 35) or (warunek);

czyli wszystkie warunki w jedym miejscu a nie - porozrzucane po calej petli. Oczywiscie probuje jedynie zrozumiec autorow tych zasad co nie znaczy, ze sie zgadzam ;)

Co do goto, mija sie z zalozeniami programowania strukturalnego :>

0

Uczepiliście się tego break jak rzep psiego ogona. Jeśli nie jest to konieczne, to nie należy używać break/continue wew. pętli - NA OGÓŁ jeśli wszystkie warunki przerwania / kontunuacji pętli są w jej nagłówku, kod jest czytelniejszy. Pisze to, bo mam dosyc czytania cudzego, niewydajnego, zle napisanego kodu, ktorego niestety pelno widze wokol siebie.

Pare czesto lamanych zasad, ktorych pozwalaja tworzyc lepszy kod w C++ (do innych jezykow niektore tez sie lapia):

  1. Czytelne i sensowne komentarze.
  2. Jednolity system nazewnictwa. Nie ważne jaki, byle naprawdę JEDNOLITY.
  3. Wskaźnikowe parametry wejściowe funkcji poprzedzone const. Nie używamy char*, tylko const char*. Każde uzasadnione użycie char* musi być dokładnie udokumentowane.
  4. Wszystkie składowe niemodyfikujące zawartości obiektu oznaczone const.
  5. Brak użycia wskaźników, jeśli nie jest to konieczne. W 99 przyp. na 100 można wskaźniki zastąpić przez wykorzystanie bibliotek (np. STL) lub referencji (&).
    5a. new/delete powinno byc dozwolone tylko dla hackerow. Nie nalezy dzieciom dawac do zabawy niebezpiecznych zabawek. Jesli nie umiesz uzywac new/delete zainwestuj w odsmiecacz lub pisz w Javie / C#.
  6. Użycie makr tylko do włącznia nagłówków i kompilacji warunkowej.
  7. Użycie std::string lub innych tego typu zamiast char* i const char*.
  8. Umieszczanie jednej logicznej funkcji w jednej linii.
    Zle:
    Tablica[I++] = 1;
    Dobrze:
    Tablica[I] = 1;
    I++;
  9. Optymalizacje robi sie na koncu lub w ogole sie nie robi. Optymalizuje sie tylko krytyczne fragmenty kodu. Optymalizacja naruszajaca czytelnosc kodu bardzo rzadko jest uzasadniona.
  10. Czytelniejszy kod => kod latwiejszy do zoptymalizowania => szybszy kod.
  11. Poprawna obsluga bledow - sprawdzanie poprawnosci danych wejsciowych do funkcji, uzywanie mechanizmu wyjatkow.
    11a. Uzywanie kontenerow sprawdzajacych zakres. Tego punktu nie spelnia STL. Nikt nie lubi szukac pol godziny gdzie jest buffer overflow.
  12. Maksymalna liczba wciec (zagniezdzen petli, warunkow) nie powinna przekraczac 6-8.
  13. Cialo funkcji powinno miescic sie w calosci na ekranie.

To tyle. Nie wzialem tych punktow z zadnej ksiazki, jeszcze pare lat temu nie stosowalem sie do wiekszosci z nich. To przychodzi z czasem. Rozumne stosowanie wszystkich tych punktow na raz prowadzi do znaczacej poprawy jakosci programow oraz stosunkow z pozostalymi czlonkami zespolu programistycznego. Wszystkie dobre firmy maja narzucone podobne zasady.

1 użytkowników online, w tym zalogowanych: 0, gości: 1