伝わらない命名をしない 名前はとても大事なものです、ロジックに反した名前を付けてしまうとレビュアーは？となります 『プログラマが知るべき97のこと』の日本語訳版でmatzさんも寄稿されていましたね どうやるか？ Google翻訳を使わない 本質的な名前を導…

問題を解決するためだけにコードを書く 当ブログで一番伝えたかったことです コードを書くのは最終手段 コードは必然的に書かなければならない時にのみ書かれるべきです なぜならば、不要なコードは常に単なる複雑さを提供するだけのものだからです バグを生…

ライブラリのコードを隠蔽する 私は今、PHPでLaravelを使うプロジェクトに参加しています ジョイン当初に驚いたのは下記の様なコードが散見されていたことです return response()->json($result); 論点は2つ ライブラリに致命的な脆弱性が見つかった際に徹夜…

条件分岐の順番にも気を使おう こういった条件分岐を見るとモヤモヤします if ($foo->exists()) { // DBにレコードがなければFALSE return false; } elseif (isset($parameter['bar'])) { // パラメータにbarが含まれなかった場合はFALSEを返す return false…

例外を拾おう 正確には正しく拾い、投げ捨てることをしない様に努めましょう こういうコードを見るととてもモヤモヤします。そして不安になります try { // 例外が発生するかも知れない処理 } catch (Exception e) { } 何がよくないか？ まず、例外が発生し…

UNIXコマンドを味方にしよう 今日はレビュー自体の話でなく、レビューを依頼する際にしておきたい事前準備の話をしたいと思います IDEやGUIツールを窓から投げ捨てよう IDEやGUIツールは非常に便利です。否定はしません ただ、こういったツールには一つの弱…

コードフォーマッタを使おう インデントや、スタイルの指摘は機械に任せようという話 規約を破るのが人間 コーディング規約に沿わないコードを書くこともある コーディング規約にないからと時代遅れも甚だしいコードを書くこともある うっかり、スペースを消…

トランザクション内で行うべきことは更新処理のみ トランザクションを開始してから更新対象を取得している処理 モヤりませんか？ どうしてそう思うのか？ トランザクションはアトミックな処理を保証するもの 一方でアトミックでない処理にならない様にロック…

目的と効果を明らかにする レビュー依頼は依頼だよねという話 依頼時あるある 口頭でお願いされる 少なくともチャットなりのテキストに残しましょう 障害対応のhotfixなら仕方ないけど、それでも後でテキストに残しましょう お願いしますだけ Aさん: これレ…

長いPRは避ける 新規開発とかをしていると起こりがちなのが数千行にも及ぶ差分 数千行ものコードを正しくレビューできる人間なんてそうそういない 少なくとも自分は何かを見落とす自信がある どうすればよかったのか？ 機能ごとの開発に切り分ける それでも…

不等号の向きは合わせる こういう複合条件の場合に頭の中で反転させることをなくしたい if ($i > 1 && $i < 100) { // 何らかの処理 } この様に書くと直感的になる if (0 < $i && $i < 100) { // 何らかの処理 } これもPBP(Perl Best Pracitice)に書かれてい…