コードの匂いはクラシックです。 においがするのは、編集または改善できる場合が多いためです。 これらの臭いのほとんどは、何かが間違っている可能性があることを示しているだけです。したがって、それ自体を修正する必要はありません…（ただし、調べておく必要があります）。 前 コードの匂い 以前のコードの匂い (パート i - XXIX) はすべて 見つけることができます。 ここで 続けましょう... Code Smell 146 - ゲッターコメント コメントはコードの匂いです。ゲッターは別のコード臭です。何だと思う？ TL;DR: ゲッターを使用しないでください。ゲッターにコメントしないでください 問題 コメントの乱用者 可読性 ゲッター ソリューション ゲッター コメントを削除する ゲッターを削除 環境 数十年前、私たちはすべての方法についてコメントしていました。些細なことでも。 コメントは、重要な設計上の決定のみを説明する必要があります。 サンプルコード 間違い pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } } 右 pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } } 検出 半自動 [x] メソッドがゲッターであり、コメントがあるかどうかを検出できます。 例外 関数にはコメントが必要です。これは誤ってゲッターであり、コメントは設計上の決定に関連しています タグ コメント 結論 ゲッターにコメントしないでください。 それらは真の価値をもたらさず、コードを肥大化させます。 関係 Code Smell 05 - コメント乱用者 Code Smell 68 - ゲッター Code Smell 01 - 貧血モデル クレジット UnsplashのReimond de Zuñigaによる写真 ほとんどのコメントを避けるために、コードは非常に表現力豊かでなければなりません。いくつかの例外がありますが、間違っていることが証明されるまで、コメントは「表現の失敗」と見なすべきです。 ロバート・マーティン ソフトウェアエンジニアリングの名言 Code Smell 147 - メソッドが多すぎる Util クラスは、プロトコルを収集するのに最適です。 TL;DR: クラスに偶発的なプロトコルを追加しないでください 問題 可読性 単一責任違反 悪い結束 ハイカップリング 再利用性が低い ソリューション クラスを壊す 抽出クラス リファクタリング リファクタリング 007 - クラスの抽出 環境 私たちは、見つけた最初のクラスにプロトコルを入れる傾向があります。 問題ない。 リファクタリングするだけです。 サンプルコード 間違い public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } } 右 public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } } 検出 自動 [×] ほとんどのリンターはメソッドをカウントして警告します。 関係 Code Smell 124 - 分岐変化 Code Smell 143 - データの塊 Code Smell 94 - インポートが多すぎる Code Smell 22 - ヘルパー Code Smell 34 - 属性が多すぎる より詳しい情報 リファクタリングの達人 タグ 凝集 ブローターズ 結論 クラスとプロトコルを分割することは、小さくて再利用可能なオブジェクトを優先するための良い方法です。 クレジット による写真 Unsplashの Marcin Simonides メンテナンスによって悪化させられないほど大きく、ねじれ、複雑なコードはありません。 ジェラルド・M・ワインバーグ コードの匂い 148 - ToDo 私たちは未来の自分のために借金をします。返済時期です。 TL;DR: コードに TODO を残さないでください。それらを修正してください！ 問題 技術的負債 可読性 自信の欠如 ソリューション TODO を修正する 環境 コード内で TODO に遭遇します。それらを数えます。 私たちはめったにそれに対処しません。 私たちは技術的負債を負い始めました。 次に、借金＋利息を支払います。 数か月後、元の借金よりも多くの利息を支払います。 サンプルコード 間違い public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { // TODO: Implement close door and cover it } } 右 public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { this.isOpened = false; } } 検出 自動 [×] TODO を数えることができます。 タグ 技術的負債 結論 TODO を数えることができます。 ほとんどのリンターはそれを行います。 それらを減らす政策が必要です。 TDD を使用している場合は、欠落しているコードをすぐに記述します。 このコンテキストでは、TODO は、Depth First 開発を行って訪問するオープン パスを記憶する場合にのみ有効です。 より詳しい情報 ToDoは入れるべき？ 壊れた窓理論 クレジット による写真 Unsplashの Eden Constantino プロジェクトの最初の 90% を完了したら、残りの 90% を完了する必要があります。 マイケル・アブラッシュ Code Smell 149 - オプションの連鎖 私たちのコードはより堅牢で読みやすくなっています。しかし、敷物の下に NULL を隠します。 TL;DR: Null と undefined は避けてください。それらを回避する場合、オプションは必要ありません。 問題 ヌル IF汚染 ソリューション ヌルを削除 未定義の扱い 環境 、 Optionals 、 Coalescence 、およびその他の多くのソリューションは、悪名高い null に対処するのに役立ちます。 Optional Chaining コードが成熟し、堅牢になり、null がなくなったら、それらを使用する必要はありません。 サンプルコード 間違い const user = { name: 'Hacker' }; if (user?.credentials?.notExpired) { user.login(); } user.functionDefinedOrNot?.(); // Seems compact but it is hacky and has lots // of potential NULLs and Undefined 右 function login() {} const user = { name: 'Hacker', credentials: { expired: false } }; if (!user.credentials.expired) { login(); } // Also compact // User is a real user or a polymorphic NullUser // Credentials are always defined. // Can be an instance of InvalidCredentials // Assuming we eliminated nulls from our code if (user.functionDefinedOrNot !== undefined) { functionDefinedOrNot(); } // This is also wrong. // Explicit undefined checks are yet another code smell 検出 自動 [×] これは です。 言語機能 検出して削除できます。 タグ ヌル 結論 多くの開発者は、null 処理でコードを汚染しても安全だと感じています。 実際、これは NULL をまったく扱わないよりも安全です。 、 Truthy 、 Falsy もコードの匂いです。 Nullish Values もっと上を目指して、よりクリーンなコードを作る必要があります。 点: コードからすべての null を削除します。 良い 点: オプションのチェーンを使用します。 悪い ：ヌルをまったく扱わない。 醜い 関係 Code Smell 145 - 短絡ハック コードの匂い 12 - ヌル Code Smell 69 - ビッグバン (JavaScript とんでもないキャスティング) より詳しい情報 オプションの連鎖参照 Null: 10 億ドルの間違い 煩わしい IF を永遠に取り除く方法 何？ クレジット Unsplashの 写真 engin akyurt による 怪物と戦う彼は、それによって怪物にならないように気をつけているかもしれません。そして、深淵をじっと見つめていれば、深淵もまたあなたを見つめている。 ニーチェ Code Smell 150 - 等しい比較 すべての開発者は属性を等しく比較します。彼らは間違っています。 TL;DR: エクスポートして比較するのではなく、比較するだけです。 問題 カプセル化の中断 コードの複製 情報隠蔽違反 違反 擬人化 ソリューション 単一のメソッドで比較を非表示にする 環境 私たちのコードでは、属性比較が頻繁に使用されています。 私たちは行動と責任に焦点を当てる必要があります。 他のオブジェクトと比較するのは、オブジェクトの責任です。私たちのものではありません。 時期尚早のオプティマイザーは、これはパフォーマンスが低いことを教えてくれます。 彼らに本当の証拠を求めて、より保守しやすい解決策と対比すべきです。 サンプルコード 間違い if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive 右 if (address.isAtStreet('Broad Street') { } // ... if (location.isAtStreet('Bourbon St') { } // 15000 usages in a big system function isAtStreet(street) { // We can change Comparisons to // case sensitive in just one place. } 検出 半自動 [x] 構文ツリーを使用して属性比較を検出できます。 他の多くの匂いと同様に、プリミティブ型にも適切な用途があります。 タグ カプセル化 結論 責任を 1 か所に置く必要があります。 比較もその一つです。 ビジネス ルールの一部が変更された場合、 を変更する必要があります。 1 つのポイント 関係 Code Smell 63 - 機能羨望 Code Smell 101 - ブール値との比較 Code Smell 122 - 原始的な強迫観念 クレジット Unsplashの 写真 Piret Ilver による ソフトウェアで最も重要なのは動作です。それはユーザーが依存するものです。ユーザーは、私たちが振る舞いを追加することを好みますが (それが彼らが本当に望んでいたものである場合)、彼らが依存する振る舞いを変更または削除すると (バグを導入します)、彼らは私たちを信頼しなくなります。 マイケル・フェザーズ 次の記事: さらに 5 つのコードの匂い。

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Making security fun one episode at a time

コードの臭い部分を見つける方法 [パート XXX]

長すぎる; 読むには

Maximiliano Contieri

About Author

ラベル

Languages

この記事は...

コードの臭い部分を見つける方法 [パート XXX]

長すぎる; 読むには

Maximiliano Contieri

About Author

ラベル

Languages

この記事は...

関連ストーリー