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.

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