バグらせやすい書き方をすれば当然バグは出やすい - えびちゃんの日記
導入 rsk0315.hatenablog.com こういう話はある*1んですが、最初からバグらせやすい書き方をしておいて「バグが出たー」と言われてもそれはそうとなってしまうので、そういうのを控えるくらいのことはするべきだと思います。 書き方が悪いせいで「十分に複雑なコード」になってしまっているものもあります（もちろん概念自体が複雑なものを実装するときは複雑になって当然ですが）。 「控えるべき書き方」とか「書くときに気をつけるべきこと」とかを紹介します。 あくまで自分の主観であって、読み手の人の方針に反するのであれば強制する気はないです。「こういう書き方もあるよー」くらいに捉えてください。 導入 紹介 控えたいこと フラグ変数を乱用しない デバッグは標準エラー出力に書く 出力パートは一箇所にまとめる 計算パートと入出力パートは分ける いくつかの具体例だけで考察を終わらせない 書きながら気を
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
