プロジェクト名こそ最もよく考えるべき?
プロジェクト名なんて後から。とりあえず動くコードを考えろ。とも思いますが…
- マサカリ対策で注釈多いですがご容赦ください
- 断言口調が混ざるのは夜中でテンションが上がっているためです
- 私見。一般論になりうるかは知らん
プログラミングでは機能に名前をつける
プログラミングで最も命名する機会、悩むポイントといえば変数名だと思います。しかしそれ以外にも関数名や構造体などのデータ構造、もう少し広げればモジュール名など、プログラムには数多の名前が存在します。それと同時にそれらの命名に対する思考が必要です。
ここからは変数に限らずプログラムにおいて命名されるものを機能と呼びます。
名前の重要度はその機能の寿命
プログラムにおける名前の分かりやすさ≒命名にかける時間 という法則があると思います。必ずしもそうではないですが、ある程度の関係性はあると思いますし、コードを書いていると実際に感じます。
理想としては全ての機能に明瞭で分かりやすい完璧な命名をしたいですが、変数1つに5分も10分も[1]かけていたら、コードが一向に動くようになりません。
そこで、多くのプログラマが実践しているであろう技術が、機能の寿命によって命名コストを調整するというものです。[2] 寿命とはその機能が使われる範囲のことです。例えば、アプリの設定を以下のようなコード(架空の言語)で読み込むとします。[3]
// get_config_path()でconfigのパスを取得
let config_path = get_config_path();
// 取得したパスからファイルを読み込み設定をロード
let load_config = load_config(config_path);
// 読み込んだ設定ファイルのパスを表示
println!("loaded config: config_path");
この際、config_pathなんて長い名前でなくcon_pathとかでもいいですし、極論pとかでもいいと思います。しかしそれはconfig_pathの寿命がprintln!までだからです。コメントを無視すれば宣言後2行程度が寿命です。流石にこの長さなら、どんなエディタでも人でも視野に入らない範囲じゃないです。
もしconfig_pathの寿命が10, 30, 100を超える場合はもっと考えた方がいいでしょう。(100を超えるのはそもそもどうかと思いますが)
これは変数に限らず関数やデータ構造にも適用可能な話でしょう。
つまり機能の名前は多くの場合、定義箇所にある文脈から離れるほど意味が不明瞭になるため、距離が長くなるほどに機能名単体で意味を維持できるような命名が重要になります。また、名前の意味がはっきりするほどその名前の持つ機能が揺れず、開発者としても迷いにくくなります。
プログラムで最も寿命の長い機能は…
ここからが本題です。
ここまでの話で命名コストは機能の寿命に比例するとしましたが、そうするとプロジェクト内で最も寿命の長い機能はなんでしょう。私はそのプロジェクト(プログラム)そのものだと思います。
ということは、命名コストを最も支払うべき対象はそのプロジェクト名そのものでは?と考えたわけです。
なので、まずはプロジェクト名を考えてからコードを書くのがいいのではないでしょうか?また、プロジェクト名がはっきりするほど、そのプロジェクト(プログラム)の機能が揺れず使いやすいプログラムになるのではとも思います。
また、言語や環境によりますがプロジェクト名の変更は割と面倒なことも多いので、せっかくならテンションあがるいい名前を考えようぜってとこです。
まとめ
ただ、名前に気を取られてコードが何も進まないみたいなのは本末転倒だとも思うので、結局はバランスだとは思います。
おまけ
Rust && CLI開発ならCargo.tomlに以下を追加することで生成されるバイナリの名前つまり、コマンド名を後から変更できます。
[[bin]]
name = "ggw"
path = "src/main.rs"
あとは、プロジェクト名に関しても(若干不安要素はありますが)エディタとかコマンドでall_replaceすれば大概変更できるのではとも思います。まあ下書きとして残していいタイトル浮かんだら新しくプロジェクト作って配置し直すのもいいかも。
noteにも同じ記事があります。(宣伝)
Discussion