Ruby/Komentarze i organizacja kodu: Różnice pomiędzy wersjami

Usunięta treść Dodana treść
Nie podano opisu zmian
Nie podano opisu zmian
 
Linia 17:
Również, by ułatwić wprowadzanie dużych bloków komentarzy, interpreter Rubiego ignoruje wszystko pomiędzy linią zaczynającą się od "<tt>=begin</tt>" a drugą linią zaczynającą się od "<tt>=end</tt>".
 
<sourcesyntaxhighlight lang="ruby">
#!/usr/bin/env ruby
 
Linia 27:
**********************************************************************
=end
</syntaxhighlight>
</source>
 
=== Organizacja kodu ===
Linia 33:
Niezwykle wysoki poziom dynamizmu Rubiego oznacza, że klasy, moduły oraz metody istnieją tylko, gdy definiujący je kod zostanie uruchomiony. Jeżeli nawykłeś do programowania w bardziej statycznym języku, może to czasami prowadzić do niespodzianek.
 
<sourcesyntaxhighlight lang="ruby">
# Ponizszy kod zwraca blad: "undefined method":
 
Linia 41:
x + 1
end
</syntaxhighlight>
</source>
 
Chociaż interpreter sprawdza, czy w skrypcie nie występują błędy składniowe przed wykonaniem go, kod "<tt>def nastepca ... end</tt>" musi być zinterpretowany w celu utworzenia metody <tt>nastepca</tt>. Tak więc kolejność kodu w skrypcie może mieć istotne znaczenie.
Linia 47:
Nie zmusza to, jak mogło by się wydawać, do organizacji ściśle według stylu "od dołu do góry". Kiedy interpreter napotka definicję metody, może ona bezpiecznie zawierać niezdefiniowane referencje, dopóki będziesz pewny, że będą one zdefiniowane nim metoda zostanie wywołana.
 
<sourcesyntaxhighlight lang="ruby">
# Konwersja stopni ze skali Fahrenheita do Celsiusza, podzielona
# na dwie czesci.
Linia 60:
 
printf "%.1f jest komfortową temperaturą.\n", f_na_c(72.3)
</syntaxhighlight>
</source>
 
To podejście może wydawać się to mniej wygodne niż to, które możesz znać z Perla czy Javy, ale jest mniej restrykcyjne niż próbowanie pisania w C bez prototypów (co zawsze zmuszałoby cię do częściowego zarządzania kolejnością, co wskazuje na co). Umieszczanie kodu na najwyższym poziomie zagnieżdżenia, na końcu pliku źródłowego zawsze działa. I sprawia mniej kłopotu, niż można sądzić. Sensownym i bezbolesnym sposobem, by wymusić określone zachowanie, jest zdefiniowanie funkcji <tt>main</tt> na górze pliku i wywołanie jej z dołu.
 
<sourcesyntaxhighlight lang="ruby">
#!/usr/bin/env ruby
 
Linia 74:
 
main # ... start main.
</syntaxhighlight>
</source>
 
Pewna pomoc płynie również z faktu, że Ruby dostarcza narzędzi do dzielenia skomplikowanych programów w czytelne, nadające się do powtórnego użycia, logicznie powiązane klocki. Widzieliśmy już użycie słowa <tt>include</tt> by uzyskać dostęp do modułów. Również mechanizmy <tt>load</tt> i <tt>require</tt> są bardzo użyteczne. Instrukcja <tt>load</tt> działa tak, jakby plik do którego się ona odnosi został skopiowany i wklejony (coś jak dyrektywa preprocesora <tt>#include</tt> w C). Instrukcja <tt>require</tt> jest nieco bardziej zaawansowana, powodując, że kod będzie załadowany tylko raz i tylko wtedy, gdy będzie to konieczne.