Wikibooks

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

Przeglądaj historię interaktywnie
← poprzednia edycjanastępna edycja →
Usunięta treść Dodana treść
WizualnieWikikod
Kj (dyskusja | edycje)
1838 edycji
m nav
Szymon wro (dyskusja | edycje)
557 edycji
Nie podano opisu zmian
Linia 1:
Ten rozdział zawiera kilka praktycznych porad.
This chapter addresses a few practical issues.
Statement delimiters
 
=== Separatory instrukcji ===
Some languages require some kind of punctuation, often a semicolon (;), to end each statement in a program. Ruby instead follows the convention used in shells like sh and csh. Multiple statements on one line must be separated by semicolons, but they are not required at the end of a line; a linefeed is treated like a semicolon. If a line ends with a backslash (\), the linefeed following it is ignored; this allows you to have a single logical line that spans several lines.
Comments
 
Niektóre języki wymagają pewien rodzaj 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 traktowanych 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 linii.
Why write comments? Although well written code tends to be self-documenting, it is often helpful to scribble in the margins, and it can be a mistake to believe that others will be able to look at your code and immediately see it the way you do. Besides, for practical purposes, you yourself are a different person within a few days anyway; which of us hasn't gone back to fix or enhance a program after the passage of time and said, I know I wrote this, but what in blazes does it mean?
 
=== Komentarze ===
Some experienced programmers will point out, quite correctly, that contradictory or outdated comments can be worse than none at all. Certainly, comments shouldn't be a substitute for readable code; if your code is unclear, it's probably also buggy. You may find that you need to comment more while you are learning ruby, and then less as you become better at expressing your ideas in simple, elegant, readable code.
 
Po co pisać komentarze? Chociaż dobrze napisany kod ma tendencję do bycia dokumentowania siebie samego, skrobanie po marginesach jest często pomocne, a błę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, dla celów praktycznych, ty też jesteś inną osobą co parę dni... Kto z nas nie wrócił kiedyś do kodu programu, by go poprawić lub rozszerzyć program po pewnym czasie i powiedział, ''wiem, że to napisałem, ale co u licha to znaczy?''
Ruby follows a common scripting convention, which is to use a pound symbol (#) to denote the start of a comment. Anything following an unquoted #, to the end of the line on which it appears, is ignored by the interpreter.
 
Niektórzy doświadczeni programiści wskażą, całkiem poprawnie, ż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.
Also, to facilitate large comment blocks, the ruby interpreter also ignores anything between a line starting with "=begin" and another line starting with "=end".
 
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.
 
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>".
 
<pre>
#!/usr/bin/env ruby
 
Linia 22 ⟶ 25:
**********************************************************************
=end
</pre>
Organizing your code
 
=== Organizacja kodu ===
 
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.
Ruby's unusually high level of dynamism means that classes, modules, and methods exist only after their defining code runs. If you're used to programming in a more static language, this can sometimes lead to surprises.
 
<pre>
# The below results in an "undefined method" error:
 
Linia 33 ⟶ 39:
x + 1
end
</pre>
 
Although theChociaż interpreter checkssprawdza, overczy thew entireskrypcie scriptnie filewystępują forbłędy syntaxskładniowe beforeprzed executingwykonaniem itgo, thekod <tt>def successor ... end</tt> codemusi hasbyć touruchomiony actuallyw runcelu inutworzenia order to create themetody <tt>successor method</tt>. So theTak orderwięc inkolejność whichkodu youw arrangeskrypcie amoże scriptmieć canistotne matterznaczenie.
 
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.
This does not, as it might seem at first glance, force you to organize your code in a strictly bottom-up fashion. When the interpreter encounters a method definition, it can safely include undefined references, as long as you can be sure they will be defined by the time the method is actually invoked:
 
<pre>
# Conversion of fahrenheit to celsius, broken
# down into two steps.
Linia 50 ⟶ 58:
 
printf "%.1f is a comfortable temperature.\n", f_to_c(72.3)
</pre>
 
So while this may seem less convenient than what you may be used to in Perl or Java, it is less restrictive than trying to write C without prototypes (which would require you to always maintain a partial ordering of what references what). Putting top-level code at the bottom of a source file always works. And even this is less of an annoyance than it might at first seem. A sensible and painless way to enforce the behavior you want is to define a main function at the top of the file, and call it from the bottom.
Źródło: „https://pl.wikibooks.org/wiki/Ruby/Komentarze_i_organizacja_kodu”