先日、「保守性・管理性が劇的に上がるPHPのスマートなコードの書き方」という某社のブログエントリが話題になってましたが
それについては、もういろんな方がいろんな言及をしているので
改めて僕が言及することも無いと思うので。
で、じゃあ自分ってそういう「人に読まれること」を前提にしたコード書く時
（仕事上のプログラムは99％そうだと思うのですが）
どんなことに気をつけてるか、ブログ書いてみようかなぁ…とFacebookにぽつと書いたら
意外と需要ありそうだったので、つらつらと書いてみた。
といっても、そんな特別なことはしてない・・・と思ってます。
あと、プログラム設計上こうすべき、とか、もあることはあるんですが
それよりも、もっと「これだけは心がければ」という根本的なポイントだけ。
実際、僕がいろいろなソースコード見てて、読みやすいな、メンテしやすいなと思うのも
このポイント抑えてあるものが多いので。
英単語を省略しない
昔ながらの慣習で、返り値用の変数を「ret」「rtn」とか、
msgとかstrとかはまだ可愛いと思うのですが
例えば、「カテゴリ」を「Ctg」みたいな、母音を抜いて省略する表記を多用されると辛いなと。
で、これがスコープ範囲狭いローカル変数ならいいんですが
クラス名とかでこういう省略をされると結構厳しい。
一昔前の、iアプリ出始めの頃のプログラミングならそういう省略も必要だったでしょうが
もうきょうびそういうのはいいんじゃないかなと。*1
英語のスペルミスをしない
英単語を省略しない、てのとも近いのですが、地味に気になるのがこれ。
率いる人の意味の「リーダー」を「reader」と平然としてあったり。
ガラケー全盛期によくあったのは、携帯キャリアの「Carrier」を「Career」(こっちは経歴の意)とか。
「アバター」も「Avater」って頻出間違いパターン。（正しくは「Avatar」）
複数形変化の間違いも多いっすね。「Abilitys」とか。（正しくは「Abilities」）
こういうのが積もり積もると、地味に読みにくい。ストレスになる。
例えば、コーディングしている環境が、セキュリティの都合上、インターネットに繋がりません
ってのであればしょうがないですが
きょうび、英語のスペルなんて、Web辞書で1分もあれば調べられるじゃないですか。
さらに言えば、今どきのIMEはカタカナ語辞典ってのがあって、
「いんたーねっと」って打てば「Internet」が候補にでてくるでしょ。
スペルチェック機能があるようなエディタやIDEもあるでしょうし。
で、ここが大事なところで、一番言いたいところなんですが
そういう細かいところに行き届かない人が書いたコードって
実際のプログラムも、動作的に行き届いてない、残念なものが多いような傾向があるように思います。
あと、いい加減、IT業界最頻誤用英語「regist」*2も撲滅したいなぁ。。。
（registという英単語はありません。正しくはregister）
同じ概念を示すものは言葉を統一する
例えば、課金を扱う処理を書いていて
あるところでは「Payment」って単語が使われているんだけど
別のところでは「Purchase」が使われているとか。そういうこと。
ソシャゲ業界あるあるとしては、「ガチャ」が「Gacha」だったり「Gatya」だったり。
そういう表記ゆれを許さない。統一する。
以前の仕事で、自分が某ソシャゲを設計した時は
最初に「用語集と使用英単語」の表を作ってました。
「風」は「wind」を使いましょう（airではなく）とか。
ここまで３つは、プログラムとは全然関係ない
どちらかというと、英語力というか、それ以前の（日本語で文章書く時だって同じ問題あるし）
表記ゆれをさけるとか、そんなことばっかですね。
人によっては、そんなの下らねえよ、って思う人もいるかもですが
こういったところにきちんと行き届いているソースコードって
ほんと読みやすいし、メンテしやすいですよ。
これだけでも充分かと思うのですが、一応プログラムに関したことも２つほど。
ネストをできるだけ抑える。elseもできるだけ避ける
有名な「オブジェクト指向エクササイズ」というやつにもでてきますが
できるだけネストを避ける。
できれば1段階まで。
許容できたとしても3段かな。
その3段全体が、エディタ1画面で収まるボリュームという前提で。
それ以上になるようなら、そもそも設計がおかしいです。
elseもできるだけ避けたいですね。
returnで早返しするテクニック使えば、結構elseは削減できるはず。
関数・メソッドの引数の数をできるだけ抑える
これも、個人的な理想値は２つまで。
座標系を扱うコンストラクタだと、３つ４ついっちゃうけど、それは例外かな。
これも、引数が５個も６個もいるような関数・メソッドは
そもそも設計がおかしいことが大半だと思ってます。
まとめ
もちろんもっと細かいルールとか、先人の知恵を踏襲すべきところは
たくさんあるとは思うのですが
そういうのは「リーダブルコード」とか「リファクタリング」とか
「Clean Code」読んでね、ということにして。
ネストの話と引数の話は、やや付け足し感あるのですが
その前の、命名に関する部分はほんとすごく大事だと思ってます。
ソースコードは書くことよりも読むことのほうが圧倒的に多いので
それこそ、ブログ文章を校正するのと同じように（校正しない人も多そうだけど）
ソースコードもそういう意識で書いていくと
それだけでも、だいぶ読みやすいコードになるよ、と思っております。
おまけ
最初に触れない、と言っておきながら、やっぱ事の発端になったブログの件。
超カンタンにだけ触れると。
- カッコの省略 原則ダメ。*3
- 三項演算子 あれは例が悪い。ネストはダメ、節度もって使うならあり。
- switch文 ポリモーフィズム使え…という人もいて、そうした方がいい時ももちろんあるけど、そこまで複雑性持ち込まなくて良い場合はswitchでもいいかと。
- for文 これも例が悪い。でも他の人も指摘してるけど、そもそもPHPだとforeach使うほうが圧倒的に多いのでは？
- 配列への要素追加 array_push()そういやそんな関数あったねｗ
- 引数のデフォルト値 例が悪すぎる
- global宣言 これは全力でダウト。ダメ、絶対。
- 条件式での代入 これ、今どきならIDEが警告するっしょ。これも原則ダメ。
- 文字列への変数挿入 僕ならsprintf()使う。
- empty() PHPの暗黙の型変換という闇の世界に誘われるよｗ 原則、イコール３つの厳密比較使うべき
- 再帰処理 再帰自体はもちろんいいんだが、この他の11個の並びと比べると、この中に再帰がでてくるのは違和感ある
- 結合代入演算子 これも例が悪くて、変数の使い回し自体が問題かな。あと、ピリオドって見落としやすいからそもそも可読性悪くない？ なのでsprintf()派。
