Update state machine.

arm_asm.md

@@ -2966,18 +2966,29 @@ C言語プログラマ以外でもステートマシーンは出てくるので
 
 終状態では別にwhileに戻らずreturnしてしまっても構いません。
 
-別に細部が違ってても構いませんが、こっそりあるstateの処理を別の状態のcaseの中でもやる場合がある、とかそういうのはやめた方が良い。
-
 ステートマシーンのポイントは各caseではその状態の処理しかしない、という事です。
 他の処理がしたい時は次の状態にいちいち遷移させて、そこでやる。
 caseの中で変なif文とか足して処理しない。
 
-普通は同じ事をやるコードを書くと、ステートマシーンで書く方がコードは長くなります。
+つまりこっそりあるstateの処理を別の状態のcaseの中でもやる場合がある、とかそういうのはやめた方が良いという事ですね。
+
+別に細部が違ってても構いませんが、
+
+- 状態の遷移
+- 各状態での処理
+
+の二つはきっちり分ける、というのは守りたい（自分はこれを守っている限りステートマシーンと思います）。
+
+なんでもありのループよりも各状態での処理と状態間の遷移を分ける、という制約で考えた方が、複雑な問題を処理しやすい事がある、というのはちょっと面白いですね。
+
+普通は同じ事をやるコードを書くと、普通に書いた場合と比べて、ステートマシーンで書く方がコードは長くなります。
 不要にstateを変えたりせずに次の状態の処理も一か所で書いてしまう方が短く書ける事は多い。
 
 このあえて制約の多いスタイルで書く事で、遷移図と一対一に対応するようになり、
 読む人も遷移図を書いて読めるようになる、というメリットがある訳です。
 
+また、一つの状態のcaseがなんか複雑だなぁ、と思う場合、新たな状態を考えてみると一見存在してなさそうな状態が実はあった、みたいな事も良くあります。
+複雑なcaseの中を新しい状態の処理に出来ないか？と考えるのは、コードを整理する良い戦略です。
 
 ### 文字列リテラルをパースするparse_stringを書いてみよう