はじめに
これまで自身が作った、遭遇したダメパターンのコード集を今年も書きたいと思います。
ネストが深くて何がしたいかわからない
以前の手続きが長いにも似ていますが、ネストが深くなるパターンです。
頭の中にあるものを整理せず書くとこれが出てきます。
function procData(data) {
if (data.items) {
if (data.items.length > 0) {
for (var i = 0; i < data.items.length; i++) {
if (data.items[i].value) {
console.log(data.items[i].value);
・・・
列名を頑張って英訳しすぎる
論理名を定めるとすべて英訳したくなるものではありますが、全てを英訳して長くなりすぎるパターンで
購入履歴詳細→detailed_purchase_historyですが、テーブルの構成にもよりますが、 detailed やhistoryでも十分伝わる場合が多いと思います。
正確に書きたくなる気持ちはわかりますが、最短で伝わる言葉を選択することが重要かなと思います。
データベースの列名も同じなのですが、フレーズに対して単語表を作ってルール化しよう！と思うのですが、心の中では「形骸化するんだろうなぁ。。。」と思ってます。
レビューをしっかりしている組織であればこの辺チェックしているでしょうが、組織毎の事情はあるでしょう。
そういった場合は何回も使って慣れさせる！実効支配する！というのもありだと思います。
私も含め英語を使われるとわからない人もいるでしょう。
間違っていようがなんだろうが良いと思います。
例えば(ひどい例で)、
郵便番号→jpCode
普通はzipCodeでしょうが、これも使い続けると良くも悪くも浸透してしまいます。
命名が統一されてない
同じ意味を示す言葉でも例えばファイルが異なる、担当が異なると変わってしまうというのはよくあるのではないでしょうか？
- ユーザー情報: userData, userInfo
- 商品情報を表す変数: itemInfo, goodsInfo
- 状態を表すフラグ: flag, status
そりゃ大企業様はこのあたりの開発規定がしっかりあるでしょう。
が、この辺り整理できていない組織はおおいのではないでしょうか？
なんなら自分単独でもやりかねないので、このあたりをAIなり、ソースコードレビューなりで統一化したほうがいいでしょう。
エラー時スタックトレースをユーザに見せるだけ
try-catheしてエラーオブジェクトなどが、そのまま出る！というパターンです。
デバッグ段階ではいいですが、概ねスタックトレースなり、技術的なメッセージなりユーザからしたら壊れた！と思わせるようなものが表示されることになります。
ちゃんと起こり得るエラーパターンを検討して、それぞれユーザに何を求めるべきなのかを示すべきでしょう。
終わりに
コーディングそのものをする機会が少なくなりクソコードを排出する事が少なくなってきました。
ただダメなコードを書いた後に、自分でだめだったなと思えること。それが大事だと思います。
コードを提出される側もすべてが完璧！ではなく自分で振り返ることができる余地も残すようにしないとなと最近は思うようになりました。