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

Usunięta treść Dodana treść
Szymon wro (dyskusja | edycje)
Szymon wro (dyskusja | edycje)
Nie podano opisu zmian
Linia 5:
=== Separatory instrukcji ===
 
Niektóre języki wymagają pewienpewnego rodzajrodzaju znaków przestankowych, często średników (<tt>;</tt>), by zakończyć każdą instrukcję w programie. Zamiast tego Ruby podąża za konwencją używaną w powłokach systemowych takich jak ''[[w:sh|sh]]'' i ''[[w:csh|csh]]''. Wiele instrukcji w jednej linii musi być odseparowanych średnikami, ale nie są one wymagane na końcu linii. Znak końca wiersza traktowanychtraktowany jest jako przecinek. Jeżeli linia kończy się znakiem odwróconego ukośnika (<tt>\</tt>), znak końca linii jest ignorowany, co pozwala na utworzenie jednej linii logicznej podzielonej na kilka liniiczęsci.
 
=== Komentarze ===
 
Po co pisać komentarze? Chociaż dobrze napisany kod ma tendencję do bycia dokumentowania siebie samego siebie, skrobanie po marginesach jest często pomocne, a. błędemBłędem jest sądzić, że inni będą w stanie spojrzeć na nasz kod i natychmiast zobaczyć go w ten sposób co ty. Poza tym, dlapraktycznie celówrzecz praktycznychbiorąc, ty też jesteś inną osobą co parę dni... KtoKtóż z nas nie wrócił kiedyś do kodu programu, by go poprawić lub rozszerzyć programi po pewnym czasie inie powiedział,: ''wiem, że to napisałem, ale co to u licha to znaczy?''
 
Niektórzy doświadczeni programiści wskażą, całkiem poprawniesłusznie, że sprzeczne lub przestarzałe komentarze mogą być gorsze niż żadne. Z pewnością, komentarze nie powinny być substytutem czytelnego kodu. Jeżeli twój kod jest nieczytelny, prawdopodobnie zawiera również błędy. Możesz odkryć, że potrzebujesz więcej komentować, gdy uczysz się Rubiego, a mniej, jak staniesz się lepszy w wyrażaniu pomysłów w prostym, eleganckim, czytelnym kodzie.
 
Ruby podąża za ogólną konwencją skryptów, która używa symbolu <tt>#</tt> by oznaczać początek komentarza. Wszystko co występuje za znakiem <tt>#</tt> do końca linii jest ignorowane przez interpreter.
Linia 22:
=begin
**********************************************************************
To jest komentarz blokowy. Cos co piszesz dla innych czytelnikow,
This is a comment block, something you write for the benefit of
i rowniez dla siebie. Interpreter zignoruje ten tekst. Nie trzeba
human readers (including yourself). The interpreter ignores it.
w nim uzywac '#' na poczatku kazdej linii.
There is no need for a '#' at the start of every line.
**********************************************************************
=end
Linia 34:
 
<pre>
# ThePonizszy belowkod resultszwraca in anblad: "undefined method" error:
 
puts successornastepca(3)
 
def successornastepca(x)
x + 1
end
</pre>
 
Chociaż interpreter sprawdza, czy w skrypcie nie występują błędy składniowe przed wykonaniem go, kod "<tt>def successornastepca ... end</tt>" musi być uruchomionyzinterpretowany w celu utworzenia metody <tt>successornastepca</tt>. Tak więc kolejność kodu w skrypcie może mieć istotne znaczenie.
 
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.
 
<pre>
# Konwersja stopni ze skali Fahrenheita do Celsiusza, podzielona
# Conversion of fahrenheit to celsius, broken
# downna intodwie two stepsczesci.
 
def f_to_cf_na_c(f)
scaleskala(f - 32.0) # ThisTo isjest areferencja forwarddo referenceniezdefiniowanej jeszcze metody, butale to it'snie okayszkodzi.
end
 
def scaleskala(x)
x * 5.0 / 9.0
end
 
printf "%.1f isjest akomfortową comfortable temperaturetemperaturą.\n", f_to_cf_na_c(72.3)
</pre>
 
TakTo więc, podczas gdypodejście może wydawać się to mniej wygodne niż to, coktóre możesz stosowaćznać wz PerluPerla czy JavieJavy, ale jest to mniej restrykcyjne niż próbowanie pisania w C bez prototypów (co zawsze będziezmuszałoby cię zmuszać 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 to 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.
 
<pre>
Linia 68:
 
def main
# tutaj logika nawyższego poziomu
# Express the top level logic here...
end
 
# ... dodatkowy kod ...
# ... put support code here, organized as you see fit ...
 
main # ... and start execution heremain.
</pre>
 
PomagaPewna pomoc płynie również z faktu, że Ruby dostarcza narzędzianarzę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 uzystakćuzyskać dostęp do modułów. Odkryjesz również, żeRó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ę onona odnosi został skopiowany i wklejony (coś jak dyrektywa preprocesora <tt>#include</tt> w C). Instrukcja <tt>require</tt> jest nieco bardziej zaawansowanezaawansowana, powodując, że kod będzie załadowany tylko raz i tylko wtedy, gdy będzie to konieczne.
 
=== To tyle... ===