paint-brush
コードの臭い部分を見つける方法 [パート XXI]@mcsee
500 測定値
500 測定値

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

Maximiliano Contieri10m2022/07/24
Read on Terminal Reader
Read this story w/o Javascript

長すぎる; 読むには

編集または改善できる可能性がある多くのインスタンスがある可能性があります。これらの臭いのほとんどは、何かが間違っている可能性があることを示しているだけです。それ自体を修正する必要はありません… (ただし、調べておく必要があります。) コードの匂いの匂いは古典的です。においがするのは、間違っている可能性のある多くの例があるためです。においは直す必要はありませんが、もっとよく見てください。クラシッククラシックです。コードの匂いは古典的ですが、コードの匂いを改善する方法はたくさんあります。

Company Mentioned

Mention Thumbnail
featured image - コードの臭い部分を見つける方法 [パート XXI]
Maximiliano Contieri HackerNoon profile picture

コードの匂いは古典的です。

においがするのは、編集または改善できる場合が多いためです。


これらの臭いのほとんどは、何かが間違っている可能性があることを示しているだけです。それらはそれ自体を修正する必要はありません…(ただし、調べておく必要があります。)


前 コードの匂い

続けましょう...



Code Smell 101 - ブール値との比較


ブール値と比較すると、魔法のキャストを実行し、予期しない結果が得られます。

TL;DR: true と比較しないでください。あなたが正しいか、間違っているか、比較するべきではないかのどちらかです


問題


ソリューション

  1. ブール値を使用
  2. ブール値とブール値のキャスト可能なオブジェクトを混在させないでください


環境

多くの言語は、値をブール交差ドメインにキャストします。


サンプルコード

違う

#!/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 を避ける


問題

  • 可読性


ソリューション

  1. 抽出方法
  2. ブール条件を組み合わせる
  3. 偶発的な 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 ステートメント


より詳しい情報



ソフトウェア エンジニアリングの目的は、複雑さを作成することではなく、制御することです。

- パメラ・ザベ




Code Smell 103 - 二重カプセル化


独自のアクセサ メソッドを呼び出すことは、カプセル化の良いアイデアに思えるかもしれません。そうではありません。


TL;DR: 私的な使用であっても、セッターとゲッターを使用しないでください


問題

  • セッター
  • ゲッター
  • プライベート属性の公開


ソリューション

  1. セッターを削除する
  2. ゲッターを削除
  3. 属性を保護する


環境

二重カプセル化の使用は、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 をアサートしないでください


問題

  • フェイルファストの原則


ソリューション

  1. ブール条件をより適切に書き換えることができるかどうかを確認します
  2. 優先 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 - ブール変数


より詳しい情報


クレジット

UnsplashJoëldeVriendによる写真


「上位互換性」の意味をようやく学びました。これは、過去の過ちをすべて保持できることを意味します。

-デニー・ヴァン・タッセル




Code Smell 105 - コメディアンの方法


専門的で意味のある名前を使用する


TL;DR: 非公式または攻撃的にならないでください


問題

  • 可読性
  • 専門外の仕事


ソリューション

  1. 適切でプロフェッショナルな名前を選択してください。


環境

私たちの職業には創造的な側面があります。


時々私たちは退屈して、面白くしようとします。


サンプルコード

違う

function erradicateAndMurderAllCustomers(); // unprofessional and offensive


function deleteAllCustomers(); // more declarative and professional


検出

  • [x]半自動

禁止語のリストを取得できます。

コードレビューでも確認できます。

名前は文脈に依存するため、自動リンターにとっては難しい作業です。

命名規則は一般的なものにする必要があり、文化的な専門用語を含めないでください。


タグ

  • ネーミング


結論

コード内で名前を付ける方法については、プロ意識を持ってください。


変数にばかげた名前を付けてコメディアンになろうとしないでください。


将来のソフトウェア開発者 (あなたも) が簡単に理解できるように、製品コードを作成する必要があります。


関係

Code Smell 38 - 抽象的な名前


より詳しい情報


クレジット

UnsplashのStewart Munroによる写真


この「ユーザーは馬鹿で、機能性に惑わされている」という Gnome のメンタリティは病気です。ユーザーがばかだと思うなら、ばかだけがそれを使用します。

-ライナス・トーバルズ


ソフトウェアエンジニアリングの名言



そして、それは今のところすべてです…

次の記事では、さらに5つのコードの匂いについて説明します!