コードの匂いは古典的です。 においがするのは、編集または改善できる場合が多いためです。 これらの臭いのほとんどは、何かが間違っている可能性があることを示しているだけです。それらはそれ自体を修正する必要はありません…（ただし、調べておく必要があります。） 前 コードの匂い パートI   パート II   パート III   パート IV   パート V   パート VI   パートVII   パートVIII   パート IX   パート X   パートXI   パート XII   パート XIII   第14部 パート XV   パート XVI   パート XVII   パート XVIII   パート XIX   パートXX 続けましょう...  Code Smell 101 - ブール値との比較 ブール値と比較すると、魔法のキャストを実行し、予期しない結果が得られます。  TL;DR: true と比較しないでください。あなたが正しいか、間違っているか、比較するべきではないかのどちらかです 問題 隠された鋳物 最も驚きの少ない原則違反。 原則違反 フェイルファスト ソリューション ブール値を使用 ブール値と を混在させないでください ブール値のキャスト可能なオブジェクト 環境 多くの言語は、値をブール交差ドメインにキャストします。 サンプルコード 違う #!/bin/bash if [ false ]; then echo "True" else echo "False" fi # this evaluates to true since # "false" is a non-empty string if [ false ] = true; then echo "True" else echo "False" fi # this also evaluates to true 右 #!/bin/bash if false ; then echo "True" else echo "False" fi # this evaluates to false 検出 自動 [×] リンターは、明示的な比較と警告をチェックできます。 タグ 鋳物 結論 多くの非ブール値をブール値として使用することは、一般的な業界慣行です。ブール値を使用するときは、非常に厳密にする必要があります。 関係 Code Smell 69 - ビッグバン (JavaScript とんでもないキャスティング) より詳しい情報 フェイルファスト クレジット による写真 Unsplashの Michael Held うまくいかない場合は、どれだけ速くうまくいかなくても構いません。  - ミッチ・ ラヴェラ Code Smell 102 - アローコード ネストされた IF と Elses は、読み取りとテストが非常に困難です。  TL;DR: ネストされた IF は避けてください。さらに良いこと: ALL IF を避ける 問題 可読性 ソリューション 抽出方法 ブール条件を組み合わせる 偶発的な IF を削除する 環境 手続き型コードでは、複雑にネストされた if がよく見られます。このソリューションは、オブジェクト指向プログラミングよりもスクリプトに関連しています。 サンプルコード 違う if (actualIndex < totalItems) { if (product[actualIndex].Name.Contains("arrow")) { do { if (product[actualIndex].price == null) { // handle no price } else { if (!(product[actualIndex].priceIsCurrent())) { // add price } else { if (!hasDiscount) { // handle discount } else { // etc } } } actualIndex++; } while (actualIndex < totalCounf && totalPrice < wallet.money); } else actualIndex++; } return actualIndex; } 右 foreach (products as currentProduct) addPriceIfDefined(currentProduct) addPriceIfDefined() { //Several extracts } 検出 自動 [×] 多くのリンターはツリーを解析できるため、コンパイル時にネストレベルをチェックできます。 タグ 可読性 複雑 結論 、コードを見つけたときよりもクリーンなままにしておく必要があります。 ボブおじさんのアドバイスに従って この問題のリファクタリングは簡単です。 関係 Code Smell 78 - コールバック地獄 Code Smell 03 - 関数が長すぎる Code Smell 36 - Switch/case/elseif/else/if ステートメント より詳しい情報 C2ウィキ 平坦化矢印コード Refactoring.com ソフトウェア エンジニアリングの目的は、複雑さを作成することではなく、制御することです。   - パメラ・ザベ Code Smell 103 - 二重カプセル化 独自のアクセサ メソッドを呼び出すことは、カプセル化の良いアイデアに思えるかもしれません。そうではありません。  TL;DR: 私的な使用であっても、セッターとゲッターを使用しないでください 問題 セッター ゲッター プライベート属性の公開 ソリューション セッターを削除する ゲッターを削除 属性を保護する 環境 二重カプセル化の使用は、90 年代の標準的な手順でした。 私的使用であっても、実装の詳細を非表示にしたかったのです。 これは、あまりにも多くの関数がデータ構造と偶発的な実装に依存しているときに、別の臭いを隠していました。 たとえば、オブジェクトの内部表現を変更して、その外部プロトコルに依存することができます。 費用対効果は割に合わない。 サンプルコード 違う contract MessageContract { string message = "Let's trade"; function getMessage() public constant returns(string) { return message; } function setMessage(string newMessage) public { message = newMessage; } function sendMessage() public constant { this.send(this.getMessage()); // We can access property but make a self call instead } } 右 contract MessageContract { string message = "Let's trade"; function sendMessage() public constant { this.send(message); } } 検出 半自動 [x] ゲッターとセッターを推測し、それらが同じオブジェクトから呼び出されているかどうかを確認できます。 タグ カプセル化 結論 二重カプセル化は、偶発的な実装を保護するための流行のアイデアでしたが、保護以上のものを公開しました。 関係 Code Smell 37 - 保護された属性 Code Smell 28 - セッター Code Smell 68 - ゲッター より詳しい情報 スタック交換 レディット インフォワールド クレジット による写真 Unsplashの レイ・ヘネシー 変化する概念をカプセル化します。  - エーリッヒ・ガンマ Code Smell 104 - 真をアサート ブール値に対してアサートすると、エラーの追跡がより困難になります。  TL;DR: ブール値をチェックする場合を除き、true をアサートしないでください 問題 フェイルファストの原則 ソリューション ブール条件をより適切に書き換えることができるかどうかを確認します 優先 assertEquals 環境 ブール値をアサートするとき、テスト エンジンはあまり役に立ちません。 彼らは、何かが失敗したことを教えてくれます。 エラーの追跡がより困難になります。 サンプルコード 違う <? final class RangeUnitTest extends TestCase { function testValidOffset() { $range = new Range(1, 1); $offset = $range->offset(); $this->assertTrue(10 == $offset); // No functional essential description :( // Accidental description provided by tests is very bad } } // When failing Unit framework will show us // // 1 Test, 1 failed // Failing asserting true matches expected false :( // () <-- no business description :( // // <Click to see difference> - Two booleans // (and a diff comparator will show us two booleans) 右 <? final class RangeUnitTest extends TestCase { function testValidOffset() { $range = new Range(1, 1); $offset = $range->offset(); $this->assertEquals(10, $offset, 'All pages must have 10 as offset'); // Expected value should always be first argument // We add a functional essential description // to complement accidental description provided by tests } } // When failing Unit framework will show us // // 1 Test, 1 failed // Failing asserting 0 matches expected 10 // All pages must have 10 as offset <-- business description // // <Click to see difference> // (and a diff comparator will help us and it will be a great help // for complex objects like objects or jsons) 検出 半自動 [x] この条件を設定した後にブール値をチェックすると、一部のリンターは警告を発します。 より具体的なチェックに変更する必要があります。 タグ においのテスト 結論 ブール アサーションを書き直してみてください。そうすれば、失敗をはるかに迅速に修正できます。 関係 Code Smell 101 - ブール値との比較 Code Smell 07 - ブール変数 より詳しい情報 フェイルファスト クレジット の による写真 Unsplash JoëldeVriend 「上位互換性」の意味をようやく学びました。これは、過去の過ちをすべて保持できることを意味します。  - デニー・ヴァン・タッセル Code Smell 105 - コメディアンの方法 専門的で意味のある名前を使用する TL;DR: 非公式または攻撃的にならないでください 問題 可読性 専門外の仕事 ソリューション 適切でプロフェッショナルな名前を選択してください。 環境 私たちの職業には創造的な側面があります。 時々私たちは退屈して、面白くしようとします。 サンプルコード 違う function erradicateAndMurderAllCustomers(); // unprofessional and offensive 右 function deleteAllCustomers(); // more declarative and professional 検出 半自動 [x] 禁止語のリストを取得できます。 コードレビューでも確認できます。 名前は文脈に依存するため、自動リンターにとっては難しい作業です。 命名規則は一般的なものにする必要があり、文化的な専門用語を含めないでください。 タグ ネーミング 結論 コード内で名前を付ける方法については、プロ意識を持ってください。 変数にばかげた名前を付けてコメディアンになろうとしないでください。 将来のソフトウェア開発者 (あなたも) が簡単に理解できるように、製品コードを作成する必要があります。 関係 Code Smell 38 - 抽象的な名前 より詳しい情報 名前に含まれるもの クレジット による写真 Unsplashの Stewart Munro この「ユーザーは馬鹿で、機能性に惑わされている」という Gnome のメンタリティは病気です。ユーザーがばかだと思うなら、ばかだけがそれを使用します。  - ライナス・トーバルズ ソフトウェアエンジニアリングの名言 そして、それは今のところすべてです… 次の記事では、さらに5つのコードの匂いについて説明します!

Keep

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

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

長すぎる; 読むには

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

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

About Author

コメント

ラベル

この記事は

Related Stories

ユニークなエコシステムを支えるビットコインUTXOのモデル

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユニークなエコシステムを支えるビットコインUTXOのモデル

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps