Coding
新人プログラマに知ってもらいたいメソッドを読みやすくするいくつかの原則
プログラミング英語検定(これみれば変数名とか付けられる)
コーディング速度をあげるコツ
コーディング速度を上げる一番の考え方は迷いをなくすこと。
共通化したい時の考え方
- 一階層上を作りwrapする
- カリー化で適用する
- abstractで共通処理を抜き出す
リファクタリングについて
マジックナンバーをやめる
number
or string
どちらもやめるべき
新規のプロジェクトに入る時の心構え
全体がわかっていないとコードを書くことが絶対わからない。
必ず新規プロジェクトに入った際には必ず仕様やドキュメントをしっかりみること。
プログラムを書く前に考えること
書きながらロジックを構成していくのは上級者。
そうなるべきだが、まずは紙でも良いのでロジックを考える。
ロジックが完成してから書く癖を。
同じことを繰り返すな
コメントの書き方
変数名/クラス名/関数名で明白なことは書かない。
コミュニケーションでの理論で**グライスの公理(Grice’s Maxims)** というのがある。
円滑なコミュニケーションが満たすべき4つの条件を説明している。
- 量の公理(Maxim of Quantity): 情報を過不足なく提供する。
- 質の公理(Maxim of Quality): 根拠のないことを述べない。嘘をつかない。
- 関係性の公理(Maxim of Relation): 関係のないことは述べない。
- 様式の公理(Maxim of Manner): 簡潔に理路整然と述べる。
上記をコメントに落としてみる 以下のようなコメントは、グライスの公理に反しているものが多く、ソースコード上の円滑なコミュニケーションを阻害する。
- 量の公理に違反: コメントを書きすぎている/コメントが説明不足
- 質の公理に違反: コメントが間違っている
- 関係性の公理に違反: コードと関係のないコメント
- 様式の公理に違反: ストレートではなく、まわりくどい、曖昧なコメント
量の公理に違反
それぞれのステップでコメントを書くことは、あまり推奨されていない。
書きすぎると量の公理に違反する。ステップにコメントが多い場合は変数名や関数の切り出し・クラスの分割など検討すること。
良いプログラマーと悪いプログラマーのコメント意識
良いプログラマーは 少数の本当に優れたコメントを書くように務める 理由を説明するコメントを書く 大量のコメントを書くことよりも、優れたコードを書くことのほうに集中する 理にかなった有用なコメントを書く 悪いプログラマーは 優れたコメントとそうでないコメントの違いがわからない 方法を説明するコメントを書く コメントが自分以外には理解できないものであっても気にしない 不適切なコードを支える目的で多数のコメントを書く ソースファイルに冗長な情報(改版履歴など)を大量に盛り込む
正規表現でvscodeを検索する
正規表現を普段から使えるようにするための特訓として、vscodeの検索で使う。
ゲームのランタイムで正規表現を使わないとのこと(負荷が高いパターンなどあるため)