-注意してください。@c
-常に @code{@bs{}version} を含めること -- ファイルの大小にかかわらず --
-を強く推奨します。@c
-個人的な経験から言って、数年前に使っていた LilyPond のバージョンを@c
-思い出そうとすることは大変なことです。@c
-@command{convert-ly} は使用した LilyPond のバージョンを宣言することを@c
-必要とします。
-
-@item @strong{チェックを含めます}:
-@ruser{小節と小節番号のチェック}, @ruser{オクターブ チェック}。@c
-時々チェックを入れておけば、ミスをしたときに素早くそれを@c
-見つけ出すことができます。@c
-@q{時々} とはどれくらいの頻度なのでしょうか?@c
-それはその音楽の複雑さ次第です。@c
-とても簡単な音楽であれば、たぶん 1 回か 2 回です。@c
-とても複雑な音楽であれば、おそらく各小節にチェックを入れます。
-
-@item @strong{テキスト 1 行につき 1 小節にします}。@c
-音楽自体や望みの出力が複雑である場合、1 行に 1 小節だけを記述すると@c
-良い場合が多いです。@c
-画面スペースを節約するために 1 行に 8 小節も詰め込むことは、@c
-入力ファイルを @q{デバッグ} しなければならない場合に、@c
-そうするだけの価値はありません。
-
-@item @strong{入力ファイルにコメントをつけます}。@c
-コメントとして小節番号 (時々) や音楽テーマへの参照
-(@q{second theme in violins}, @q{fourth variation}
-(@q{ヴァイオリンの第 2 テーマ}, @q{第 4 ヴァイオリン})
-など) を使用します。@c
-初めて楽曲を書いているときはコメントをつける必要は無いかもしれません。@c
-しかしながら、数年後に何か変更を加えたいと思った場合や、@c
-ソースを友人に渡す場合、あなたがファイルにコメントをつけていなければ、@c
-あなたの意図やファイルがどのように構成されているのかを特定することは@c
-ずっと大変になります。
-
-@item @strong{波括弧にインデントを入れる}。@c
-多くの問題は @code{@{} と @code{@}} の数が食い違うことによって生じます。
-
-@item セクションや変数の開始時に@strong{明示的に演奏時間を付け加える}。@c
-フレーズの開始時に @code{c4 d e} (@code{c d e} ではなく) と記述しておけば、@c
-後になって音楽を再編成する場合に問題の発生を免れる可能性があります。
-
-@item 音楽定義から@strong{調整を分離します}。@c
-@rlearning{変数と関数を用いて入力の手間を省く} と
-@rlearning{スタイル シート} を参照してください。
+注意してください。
+
+@item
+@strong{入力ファイル 1 行につき、1 小節の音楽を書きます}。 これは@c
+入力ファイルに関するあらゆる問題のデバッグを簡単にします。
+
+@item
+@strong{@ruser{小節と小節番号のチェック}と@ruser{オクターブ チェック}を含めます。}@c
+入力ファイルにこのような@q{チェック}を含めておくことで、@c
+ミスを特定するのが早くなります。@c
+チェックをどのぐらいの頻度で追加するかは、その音楽の複雑さ次第です。@c
+簡単な音楽であれば、戦略上重要なポイントにいくつか追加するだけで十分でしょう。@c
+しかし、多くの声部や譜を持つようなもっと複雑な音楽であれば、おそらく各小節に@c
+チェックを入れたほうが良いでしょう。
+
+@item
+@strong{入力ファイルにコメントをつけます}。@c
+コメントとして音楽テーマへの参照
+(@q{ヴァイオリンの第 2 テーマ}, @q{第 4 変奏})
+など) や、単純に小節番号を追加することは、@c
+入力ファイルの中の場所を特定するのを簡単にします。特に後で何かを変更しなければ@c
+ならない場合や、LilyPond 入力ファイルを他の人に渡す際には特に役立ちます。
+
+@item
+@strong{セクションの開始時に明示的に演奏時間を付け加えます}。@c
+例えば、ただ @code{c d e f} と書く代わりに @code{c4 d e f} と書くことで、@c
+後で音楽を再配置するのが簡単になります。
+
+@item
+@strong{波括弧と並列表記にインデントを施します}。問題はしばしば、@c
+どちらかの括弧が@q{足りない}ことが原因です。波括弧の@q{始まり}と@q{終わり}
+(あるいは @code{<<} と @code{>>}) に明確なインデントを追加することで、@c
+このような問題を避けやすくなります。例えば以下の入力:
+
+@example
+\new Staff @{
+ \relative @{
+ r4 g'8 g c8 c4 d |
+ e4 r8 |
+ % Ossia section
+ <<
+ @{ f8 c c | @}
+ \new Staff @{
+ f8 f c |
+ @}
+ >>
+ r4 |
+ @}
+@}
+@end example
+
+@noindent
+は以下の入力より括弧の対応を追いかけやすいです:
+
+@example
+\new Staff @{ \relative @{ r4 g'8 g c4 c8 d | e4 r8
+% Ossia section
+<< @{ f8 c c @} \new Staff @{ f8 f c @} >> r4 | @} @}
+@end example
+
+@item
+@code{\layout} ブロックにオーバライドを追加することによって、@c
+@strong{音楽とスタイルを分割します}:
+
+@example
+\score @{
+ @var{@dots{}music@dots{}}
+ \layout @{
+ \override TabStaff.Stemstencil = ##f
+ @}
+@}
+@end example
+
+このオーバライドは新しいコンテキストを生成しませんが、@c
+コンテキストが生成された際に適用されます。@c
+@rlearning{変数と関数を用いて入力の手間を省く}や@c
+@rlearning{スタイル シート}も参照してください。