Bo to zła instrukcja była…

2008-06-24 21:56

Ostatnio na forum Warsztatu wyrosła dyskusja wokół niepozornej instrukcji break. Zaczęło się od zasłyszanej opinii, że korzystanie z niej jest objawem złego stylu programowania i że jest generalnie niezalecane. Argumentem na rzecz takiego twierdzenia jest to, że break jest podobny w swoim działaniu do etykiet i “wyklętej” instrukcji goto:

  1. while (WarunekPetli())
  2. {
  3.     if (CosSieStalo()) goto ZaPetla;   // prawie jak break
  4. }
  5. ZaPetla:
  6.     // ...

W sumie wyszła z tego całkiem długa polemika, która ujawniła kilka ciekawych faktów. Po pierwsze: przejrzystość kodu jest w całkiem dużym stopniu kwestią subiektywną i o ile jednemu może przeszkadzać brak (lub niewystarczająca ilość) komentarzy, to dla drugiego o wiele ważniejsze może być używanie lub nieużywanie określonych konstrukcji językowych. Po drugie: oprócz wspomnianego już goto czy wywołanego we wspomnianym wątku breaka, do instrukcji potencjalnie niepożądanych swobodnie można zaliczyć bardzo wiele innych rozwiązań – zależnie od upodobań, poczucia ‘słuszności’, bieżącej fazy księżyca i pewnie mnóstwa jeszcze innych kryteriów. I tak dostało się chociażby pętlom “nieskończonym” (typu while(true) lub for(;;)), wspomniano coś o wyjątkach, a sam napomknąłem o instrukcji continue lub “przedwczesnym” return:

  1. void Funkcja()
  2. {
  3.     if (/* warunek wyjścia */) return;
  4.     // reszta instrukcji
  5. }

Teoretycznie można by wszystkie te konstrukcje usunąć w imię ideologicznej czystości programowania strukturalnego, w którym każdy blok ma dokładnie jedno wejście i wyjście. Ale tu na szczęście wkracza wniosek trzeci: języki programowania używane w praktyce nie są żadnymi doskonałymi modelami, nad którymi należy się zachwycać. To narzędzia i jako takie powinny być przede wszystkim wygodne w użytkowaniu.
Więc nie warto drzeć kotów o sens stosowania break czy nawet goto (która to instrukcja też ma swoje zastosowania) i wydawać ogólne sądy na temat ich ‘nieprofesjonalności’. Bo nawet jeśli ta czy inna instrukcja rzekomo jest zła, to korzystający z niej kod nadal może być dobry, czytelny i łatwy do modyfikacji… Łącznie z refaktoringiem, który tego czy innego breaka może przecież usunąć ;P

Tags: ,
Author: Xion, posted under Programming, Thoughts »


3 comments for post “Bo to zła instrukcja była…”.
  1. moriturius:
    July 1st, 2008 o 9:04

    Zdaje mi się, że główną ideą programowania strukturalnego było, aby czytający kod mógł czytać go łatwo i ze zrozumieniem, bez zbędnego cudowania.

    Taki kod w Asm ze skokami w różne miejsca programu nie jest najfajniejszy do czytania ;)

    Odnosnie tematu, na podstawie tego co napisalem przed chwila powiem tylko jedno: trzeba zachować rozsądek :)

    Jeśli ktoś czyta kod i widzi break to wie dokładnie gdzie ten break skacze. Podobnie z return i continue. Przy goto dowolność jest większa, ale jeśli jest używane to zazwyczaj tak, że widać dokąd idzie ;) (przydaje sie glownie przy wychozeniu z 2 petli)

    Takie jest przynajmniej moje zdanie :)

  2. Sabre:
    October 6th, 2008 o 15:57

    Od kiedy W. Dijkstra napisal “Go To Statement Considered Harmful” nikt juz nie lubi goto. A to przeciez dobra instrukcja jest.

  3. Hilary Jendrasiak:
    September 16th, 2011 o 2:17

    Sabre- z całym szacunkiem, ale Dijkstra chyba dłużej studiował ten temat i uważniej. Ty piszesz, że jest dobrą, bowiem jest wygodna, prawda? On to napisał, bowiem spojrzał na wszystko, włącznie z burdelem jaki się tworzy w związku z forwardingiem i innymi cudami procesora.

    Nie ma algorytmu, którego nie możemy zaimplementować bez GOTO. Nie ma algorytmu, w którym zastosowanie GOTO miało jakiekolwiek znaczenie dla złożoności obliczeniowej (pozytywne, lub negatywne).

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.