ちょっとは真面目にEmacsをカスタマイズしようと思い始めた。 まず、練習題材として、elispファイルのバッファ内を整形するパッケージを書いてみた。 その時に考えたことを、メモしておく。

  • コンストラクタ、アクセッサ、トランスフォーマーで分ける。sicp方式のオブジェクト指向で書くと、自然とそれらの関数を並べていくことになる。 ポリモーフィズムや多態ディスパッチが有効に使えるのは、それなりに大きなプログラムでうまく設計されたものだけだろうとも思うが、上の設計方針を貫いたほうが良い。 中規模程度のプログラムでも、数行程度の小さな関数が、数十個並ぶことになる。このとき、名前空間が完全にフラットで、型もないので、それらの役割・振舞を識別するのは、関数名と引数名しかない。 従って、何らかのハードな内部の規約を設け、それに機械的に従うのが良い。さもないと、関数を呼ぶ度に、いちいち関数の定義やドキュメントを参照するハメになる。 規約に従っていれば、その関数が何をするものなのかが名前からハッキリと分かるのが望ましい。そのために、適切な分類階層が有効だと考える。 コンストラクタ、アクセッサ、トランスフォーマーは、ある程度まで汎用的に利用可能な分類と考える。
    • コンストラクタは<prefix>-<名前(名詞)>
    • アクセッサは<prefix>-get-<クラス名(名詞)>-<属性名(名詞)>
    • トランスフォーマは<prefix>-<処理内容(動詞)>-<目的語(名詞・任意)>という感じか
  • 基本的には、関数型的に、値の変換を繰り返すアルゴリズムて考えた方が良いような気がするが、潔癖になる必要はない。ただし、手続き的なコードは最小化・孤立化し、一つの関数に閉じ込めておき、外から見たら副作用のない関数のように見せるのが良い
  • 上の2点の方針を貫くためには、アルゴリズムの中で必要になるデータ構造（ヒープやセグメント木みたいな競技プログラム的な高度な物を意味しているわけではなく、ファイルのリスト、とか、文字列のリストと数値のペア、とか言うレベルの単純な話し）、それらに対する操作、それらの名前をよく設計する必要がある。 というか、よほど複雑な問題でもない限り、上ができれば、あとはほとんど素直にコードに書いていくだけに落ちると思われる。
  • いきなり全ての構造をキレイに設計できるわけではないので、単体テストを書き、プログラムが壊れないように頻繁にリファクタリングができることが大事