Ruby/Komentarze i organizacja kodu: Różnice pomiędzy wersjami
Usunięta treść Dodana treść
Szymon wro (dyskusja | edycje) m Ruby/Pozostałe uwagi przeniesiono do Ruby/Komentarze i organizacja kodu: Bardziej adekwatny tytuł do treści. Ten rozdział nie może być na samym końcu, gdyż zawiera informacje potrzebne dużo wcześniej. |
Szymon wro (dyskusja | edycje) Nie podano opisu zmian |
||
Linia 1:
== Komentarze i organizacja kodu ==
Ten rozdział zawiera kilka praktycznych porad, przydatnych w dalszym poznawaniu Rubiego.
=== Separatory instrukcji ===
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>".
<source lang="ruby">
#!/usr/bin/env ruby
Linia 27:
**********************************************************************
=end
</
=== 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.
<source lang="ruby">
# Ponizszy kod zwraca blad: "undefined method":
Linia 41:
x + 1
end
</
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.
<source 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)
</
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.
<source lang="ruby">
#!/usr/bin/env ruby
Linia 74:
main # ... start main.
</
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.
<noinclude>
{{ProstaNawigacja|spis=Ruby|poprzart=Ruby/Inicjalizacja obiektów|poprz=Inicjalizacja obiektów}}
| |||