622 測定値

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

に Maximiliano Contieri9m2023/01/23

長すぎる; 読むには

コードは、編集または改善できる可能性が高いため、においがします。これらのにおいのほとんどは、何かが間違っている可能性があることを示すヒントにすぎません。コメントはコードのにおいです。ゲッターは別のコード臭です。ゲッターにコメントしないでください。それらは真の価値をもたらさず、コードを肥大化させます。

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

コードの匂いはクラシックです。

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

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

前コードの匂い

以前のコードの匂い (パート 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 開発を行って訪問するオープンパスを記憶する場合にのみ有効です。

より詳しい情報

クレジット

Unsplashの Eden Constantinoによる写真

プロジェクトの最初の 90% を完了したら、残りの 90% を完了する必要があります。

マイケル・アブラッシュ

Code Smell 149 - オプションの連鎖

私たちのコードはより堅牢で読みやすくなっています。しかし、敷物の下に NULL を隠します。

TL;DR: Null と undefined は避けてください。それらを回避する場合、オプションは必要ありません。

問題

ヌル
IF汚染

ソリューション

ヌルを削除
未定義の扱い

環境

Optional Chaining 、 Optionals 、 Coalescence 、およびその他の多くのソリューションは、悪名高い null に対処するのに役立ちます。

コードが成熟し、堅牢になり、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 をまったく扱わないよりも安全です。

Nullish Values 、 Truthy 、 Falsy もコードの匂いです。

もっと上を目指して、よりクリーンなコードを作る必要があります。

良い点: コードからすべての 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. }