俺コーディングポリシー
の編集・凍結
Top
/
俺コーディングポリシー
[
トップ
] [
編集
|
凍結
|
差分
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
Active
Rubyチートシート
成果物リスト
勉強会ログ
↑
アイデア
Webサービス案
Androidアプリ案
電子工作案
GreaseMonkey案
contribute
編集
↑
Recent
2023-11-12
自動車保険
2023-08-04
HDDリスト
2023-08-03
docker
2023-05-17
Rubyチートシート
2023-03-30
RAID5/トラブル20230324
2023-03-25
PC/misuzu
2023-03-24
PC
2023-03-23
PC/DESKTOP-7SL5J8R
2022-12-16
Linux
2022-11-09
Linux/ディスクイメージ取得
2021-05-23
CTF
2021-03-17
PC/misumi
2020-08-31
COMP
2020-03-28
PC/misumi/ubuntu
Windows 10
2018-06-04
Microsoft decode 2018 2日目
Microsoft decode 2018 1日目
2018-04-07
カメラ
2018-01-06
電力自由化
2017-12-21
CROSS×BEATS
ページを凍結するにはパスワードが必要です。
B
I
U
D
H
[[]]
<br>
--
管理者パスワード:
#contents *名前付け 名前は、プログラマ同士の会話にも使われる。 良い名前をつけると、プログラムだけでなく人間のやりとりもスムーズに進む。 **短く できれば短い単語で1単語。 上限は、だいたい15文字以内・3単語以内くらい。 長いキーワードの弊害は、 -ソースにたくさん並ぶと読みにくい -記憶しにくいので、頭の中でプログラムの構造をイメージしにくくなる -似たようなキーワードが増えて、混乱する --長い名前はだいたい、ほとんど同じでどれか1単語のみ違ったりする いずれも作業効率を落とす。 **良い名前の付け方 -概念に名前をつける --頻繁に登場する概念は、頻繁に入力する文字列になる ---簡潔で、概念を的確に表現する名前を慎重に選ぶ --できれば短い一単語で ---概念のクラスには派生クラスが作られがちで、そのとき後ろに1単語ずつ増えていくことが多いので -メソッド名 --処理の内容を要約する --何をするメソッドなのか、ユーザー視点で表現する。内部実装で表現しない。 ---△ SetOriginalValue ---○ ResetValue **良い名前が付かない理由 良いコードは、良い名前の付け方を自然に実践できる。 名前付けに困るときは、たいてい良いコードが書けていないのが原因。 -クラスの役割が絞りこめていない -1つのメソッドに複数の機能を持たせている もちろん、自分のボキャブラリが足りないこともある。 Rubyのライブラリは1単語で明確な名前がついてることが多く、参考になる。 Java, C#も悪くないけど、ちょっと冗長。 **イディオム あまり世間で広まっていないモノを中心に。 -Utility --便利なstaticメソッドを集めたクラス --インスタンスメソッドにする必要がないものを外部に出しておくと、概念と実装が分かれて読みやすくなる **NGワード 次の単語はできるだけ使わない。 -object, data, info, description, instance --特に意味もないのになんとなく付けて、冗長になる --JavaのObjectクラスとか、struct名にはDataをつけるとか、明確な意味を持たせる場合はOK -manager --HogeManagerという名前をつけると、なんでもやるクラスになりがち --クラスの役割を明確にすれば、もっと曖昧さのない単語が浮かぶはず -get, set --コードがget/setだらけになるから -is --コードがisだらけになるから --英語的に自然な is〜 という名前をつけるのは日本人には難しく、創作英語が生まれる要因だから -enable, flag --様々なHogeに対して「Hogeを有効にする」という言い方ができるので、乱用するとenableHoge()だらけになる --「HogeFlagを立てる」も同様。 --単に「Hogeをする」など、簡潔な言い換えを意識する -(メソッド名) try --tryHoge()は、canHoge()とhoge()が混ざったメソッドなので、分離するべき --Mutex::tryLock()のような、本質的にatomicなメソッドはOK --Matrix::inverse()のような、判定と実行を分けると余分なコストがかかる場合もOK -(メソッド名) and, or, if --ひとつのメソッドが複数の処理をしている証拠だから --メソッドを分けるか、一連の処理に新たな名前をつけるべき -(集合の接尾辞) collection, vector, (array), (group) --スペルが長いから --複数形にして表現。setも可 --setだと、std::set型と誤解するという人もいるかなぁ -日本人の多くが知らない単語 --コードを読みながら辞書も引くのは、理解を妨げる -日本人の多くがスペルが自信ない単語 --typoが増えたり、打つのに時間がかかる --よく見るのはvisibility, referenceなど。けどこれらは代用が思いつかない… **便利な単語 英単語は日本語訳で覚えない。ニュアンスで覚える。 使おうとしている単語が適切かどうかは、英語としてのニュアンスで判断する。 和訳してから日本語で考えると、いまいちハマらない名前を選んでしまう。 以下、単語とそのニュアンスを列挙 -Resolve -Parse **名前を簡潔にするテクニック DRY原則の実践でもあります。 -名前空間・クラス・メソッドで同じ単語を含まないようにする --info::HogeInfo::createHoge() -> info::Hoge::create() --これを怠ると、どんどん名前が長くなる気がする --ディレクトリとかXMLのタグとか、階層構造を持つものならなんでも応用できる --広い範囲に影響するので、設計初期から方針を貫かないとどんどん崩れるので注意 -引数の型をメソッド名から省く。オーバーロードも活用 --addHoge(Hoge& hoge) -> add(Hoge& hoge) --findFooByBar(Bar& bar) -> findFoo(Bar& bar) -目的語をthisにする --processHoge(Hoge& hoge) -> Hoge::process() -よく使われる操作に、独自の名前をつける --isNullOrEmpty() -> isBlank() (railsにあったような) -メソッドのユーザーが何をしたいか考え、ユーザー視点で名前をつける --Queue::addLast() -> Queue::enqueue() --deleteAndSetNull() -> safeDelete() --ここでいい名前を思いつけるように、日頃からボキャブラリを多く持つ -内部実装をほどよく隠蔽し、メソッド名に必要以上の情報を盛り込まない *コメント 書くべきは、意図・要約・理由・言い訳。 コメントがなくても読めるコードが理想。 よくないコードを見たら、フォローするコメントを書くよりリファクタしたほうがいい。 日本語で挙動を表現するのはそもそも難しい。日本語に悩む時間があったら、コードをわかりやすくするのに使った方がいい。 次のようなコメントは書かない。 -言語の常識レベルの機能の説明 --「コンストラクタ」・「デストラクタ」 --「インクルード」・「関数宣言」・「関数定義」 --などなど -DRY原則違反のもの --クラス名、メソッド名、変数名を日本語訳・カタカナ表記しただけ --処理の内容をほぼ1対1で記述 --メソッドのコメントに、そのメソッドの名前を含める ---クラス・ファイルも同様 --基底クラスのコメントを、派生クラスにコピペ ---派生クラス特有の内容があれば、それだけを書く。 --罫線 ---ハイフンのコピペなので、DRY原則違反(半分冗談) 上記のようなことしか書くことがなかったら、何も書かなくていい。 すべての関数や引数にコメントをつけろ、というルールは、無意味なコメントを書くことを強制するのでよくない。 すべてにコメントをつけると統一感はあるけど、特に実益はないと思う。 それより、コメントを書くコストと、ノイズによってコードが読みにくくなることを重く見たほうがいい。 リファレンスマニュアルを自動生成する場合は、公開関数にコメントを義務づけるのはしかたないかも。 それはコードではなくドキュメントを書くコストと見なしていい。 **未来に残す言葉 良いコードが書けていないときは、メンテナンスする人向けのガイドを添えておく。 1ヶ月後の自分が助かることもよくある。 -どこどこにコピペしてあります。変更時は内容を同期してください。 -なになにの場合は、どこどこで処理しています -@todo 未実装 -@todo リファクタ(イメージがあればそれも書く) -@todo こういうケースでバグるので対応する 詳細を書く余裕がないときは、@todo の一言だけでも価値がある。 それを見て意図が分からなかったら、svn blameして書いた人に聞きに行けばいい。 **具体的に書きすぎない -汎用的な処理に、現時点で何に利用しているかを書かない --他に処理が増えたとき、コメントが古くなる --「例えば、こういう利用のために存在する」のように書く *コピペ -原則禁止 -やむを得ないときは、1回(同じモノが2つ存在)まで --その際は、できるだけ内容を変えずにコピペする ---コピペ後に微妙に書き換えてしまうと、後で関数化などするときに面倒になる。 --また、両方にどこにコピペしたかをコメントで書く -例: 内容を変えずに済むように書き換えてからコピペする ---( // before int fooSize = foo.size(); for(int i=0;i
凍結する
凍結しない
タイムスタンプを更新
テキスト整形のルールを表示する
Last-modified: 2014-12-24(水) 16:49:52