驚き最小の原則というものがプログラミングにはあります。
Wikiを見ると次のとおりです。
驚き最小の原則(おどろきさいしょうのげんそく、Principle of least astonishment または Rule of least surprise)とは、ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える(驚きが少ない)ものを選択すべきだとする考え方である。
https://ja.wikipedia.org/wiki/驚き最小の原則
普段と違う言動、行動、ソースコード、などをやめようというものですね。
そのような場合に、何があったのか気になってしまいますし、ソースコードを読みたくなくなってしまうかもしれません。
ただし、驚くようなソースコードなのか、そうではないのかは、関わるプログラムによって異なる部分になりますので、普段のソースコードをかけるようになるにはに焦点を当ててみたいと思います。
目次
ある意味驚く物語
こんな小説は嫌だ
目次で犯人がわかってしまう
主人公の話し方が統一されていない
(方言が異なっていたり、別の人が執筆したように見える)
ページを飛び飛びで読まないと物語がつながらない
ちょっと極端な例かもしれませんが、かかれた小説を読む以前の問題を列挙してみました。
ページが順番ではないとか、読む以前の問題ですよね?
ある意味読まれるかもしれませんが、驚き最小の原則では、このように普段やられないようなことは控えておこうという原則です。
一つだけ守った方が良い規約
普段のソースコードというものをなんとなくでも感じられるようになるまでには、時間がかかります。
Githubを読んだり、様々なアプリを触ってみたり、そんなことをしていくうちに、「大体ソースコードはこんな感じで別れているんだ。」「終了するショートカットはこのキーなんだ。」ということがわかってくるようになります。
この原則を守れるようになるには時間がかかるんですよね。
なので、一点だけ、守っていただきたいものをあげます。
「コーディング規約」を守りましょう。 コーディング規約は調べて出てくるようなもの、会社やプロジェクトごとに定義されているものなど様々ありますので、適切な規約を選択していただければと思います。
このような規約を守っていこうとする中で、「普段の」ソースコードと言われるようなものに意識が少しずつ向けられるようになるのではないかと思っています。意識が向けられるようになれば、ほかから吸収も少しずつできてきます。
まとめ
普段のソースコードというものをかけるようになるのは難しいです。
色々な知識があってから「普段の」ソースコードがわかるようになるためです。
なので、最低限「コーディング規約」を守って開発をするように心がけることをしていきましょう。
そうしていく中で、更に他の部分にも目が行くようになるでしょう。