5つのコードの匂いがする20話は100のコードの匂いですよね？ 前 コードの匂い パートI パート II パート III パート IV パート V パート VI パートVII パートVIII パート IX パート X パートXI パート XII パート XIII 第14部 パート XV パート XVI パート XVII パート XVIII パート XIX 続けましょう... Code Smell 96 - 私のオブジェクト オブジェクトを所有していません。 TL;DR: を名前のプレフィックスとして使用しないでください。 my 問題 コンテキストの欠如 バイジェクション断層 ソリューション プレフィックスを削除します。 私の 名前を提案する役割に変更します。 環境 いくつかの古いチュートリアルでは、'my' という単語を遅延名として使用しています。これはあいまいであり、コンテキストの間違いにつながります。 サンプルコード 違う MainWindow myWindow = Application.Current.MainWindow as MainWindow; 右 MainWindow salesWindow = Application.Current.MainWindow as MainWindow; /* Since window is instanciated, we are currently working with a specialized window playing a special role */ 検出 自動 [×] リンターと静的チェッカーに、このプレフィックスを検索して警告するように指示できます。 タグ ネーミング 結論 使用は避けてください。オブジェクトは、使用状況に応じて変化します。 my の より詳しい情報 名前とは正確には何ですか — パート II リハビリ クレジット の による写真 Unsplash MichałBożek コードを変更した私の経験を考えると、新しいコードを書くよりも、既存のコードを読むことに多くの時間を費やしていることがわかります。したがって、コードを安くしたい場合は、読みやすくする必要があります。 ケント・ベック ソフトウェアエンジニアリングの名言 Code Smell 97 - 共感のないエラー メッセージ ユーザー (および私たち自身) のために、エラーの説明には特に注意を払う必要があります。 TL;DR: 意味のある説明を使用し、是正措置を提案してください。 問題 最小の驚きの原則 ソリューション 宣言的なエラー メッセージを使用する 明確な終了アクションを表示 環境 プログラマーが UX の専門家であることはめったにありません。 また、カウンターの両側にいることができるという事実を過小評価しています。 サンプルコード 違う alert("Cancel the appointment?", "Yes", "No"); // No consequences // Options not clear 右 alert("Cancel the appointment? \n" + "You will lose all the history", "Cancel Appointment", "Keep Editing"); // Consequences are clear // Choice options have context 検出 マニュアル [×] コード レビューですべての例外メッセージを読む必要があります。 タグ 例外 UX 結論 例外を発生させたり、メッセージを表示したりするときは、エンド ユーザーのことを考える必要があります。 クレジット による写真 Unsplashの ビジュアル プログラマーが決して間違いを犯さないことは周知の事実ですが、プログラムの重要なポイントでエラーをチェックして、ユーザーをユーモアにすることは依然として良い考えです。 ロバート・D・シュナイダー Code Smell 98 - スペルミス スペルと読みやすさは人間にとって非常に重要ですが、機械にとっては重要ではありません。 TL;DR: 名前には気をつけて。 問題 可読性 コード内の用語を検索するのが難しくなります。 ソリューション コードのスペルチェック。 スペルチェックで IDE を使用する 環境 私たちの多くは、英語を第一言語として話せません。 テキストと名前には特別な注意を払う必要があります。 ベイトがあります 😀 この記事のタイトルには、コンテキストの証拠としてのタイプミスとクリック サンプルコード 違う comboFeededBySupplyer = supplyer.providers(); 右 comboFedBySupplier = supplier.providers(); 検出 タグ 可読性 ネーミング コードのスタイリング 結論 名前には細心の注意を払ってください。 おそらく、数か月後にはコードを読む人になるでしょう。 関係 Code Smell 48 - 標準のないコード より詳しい情報 名前とは正確には何ですか — パート I The Quest 名前とは正確には何ですか — パート II リハビリ クレジット による写真 Unsplashの Brett Jordan 適切に作成されたすべての大きなプログラムの中には、適切に作成された小さなプログラムがあります。 CARホアレ Code Smell 99 - ファーストセカンド 怠惰な引数名を何回目にするでしょうか? TL;DR: 偶然の位置ではなく、役割に応じて引数に名前を付けてください 問題 可読性 意図を明らかにする名前 ソリューション 意味のある名前を使用する 環境 メソッドを書くとき、私たちは通常、適切な名前を見つけるために立ち止まりません。 明らかなものをリファクタリングすることもありません。 サンプルコード 違う class Calculator: def subtract(self, first, second): return first - second class CalculatorTest def test_multiply(): assert equals(first, second) 右 class Calculator: def subtract(self, minuend, subtrahend): return minuend - subtrahend class CalculatorTest def test_multiply(): assert equals(expectedValue, realValue) 検出 マニュアル [×] 引数名として「first」や「second」などの禁止語を警告できます。 タグ 可読性 結論 常にルール提案パラメーターに従います。 役割に応じて協力者に名前を付けます。 関係 Code Smell 65 - タイプにちなんで名付けられた変数 より詳しい情報 名前とは正確には何ですか — パート II リハビリ クレジット による写真 Unsplashの Priscilla Du Preez 最終的なソース コードは、実際のソフトウェア デザインです。 ジャック・リーブス コードの匂い 100 - GoTo GOTO は 50 年前に有害と見なされていた TL;DR: GoTo を使用しないでください。 問題 可読性 コードをたどりにくい ソリューション を構造化コードに置き換える GOTO 例外を使用する 環境 Basicでプログラミングを始めました。 そこでGOTOは酷使された。 リハビリモードで構造化プログラミングをゼロから学ばなければなりませんでした。 サンプルコード 違う for x < 0 { if x > -1e-09 { goto small } z = z / x x = x + 1 } for x < 2 { if x < 1e-09 { goto small } z = z / x x = x + 1 } if x == 2 { return z } x = x - 2 p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6] q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7] return z * p / q small: if x == 0 { return Inf(1) } return z / ((1 + Euler*x) * x) } 右 for x < 0 { if x > -1e-09 { return small(x, z) } z = z / x x = x + 1 } for x < 2 { if x < 1e-09 { return small(x, z) } z = z / x x = x + 1 } if x == 2 { return z } x = x - 2 p = (((((x*_gamP[0]+_gamP[1])*x+_gamP[2])*x+_gamP[3])*x+_gamP[4])*x+_gamP[5])*x + _gamP[6] q = ((((((x*_gamQ[0]+_gamQ[1])*x+_gamQ[2])*x+_gamQ[3])*x+_gamQ[4])*x+_gamQ[5])*x+_gamQ[6])*x + _gamQ[7] return z * p / q small(x, z) { if x == 0 { return Inf(1) } return z / ((1 + Euler*x) * x) } } 検出 自動 [×] をサポートする言語では、リンターはその使用に対して警告を発することができます。 GOTO タグ 可読性 結論 私たちは、数十年前に GOTO の問題を認識していました。 この問題は、GoLang、PHP、Perl などの でも依然として存在します。 最新の言語 幸いなことに、ほとんどのプログラマーは GOTO 文を避けています。次の目標は、有害な を検討することです。 null の使用 礼儀 XKCD 関係 コードの匂い 12 - ヌル より詳しい情報 有害と見なされる後藤ステートメント ウィキペディア クレジット の による写真 Unsplash JensJohnsson BASIC に触れたことのある学生に良いプログラミングを教えることは事実上不可能です。 エドガー・ダイクストラ ソフトウェアエンジニアリングの名言 100 マイルストーンを達成しました。 次の記事では、さらに5つのコードの匂いについて説明します!

Alphabet

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

Share your ideas with me !

Read My Stories

Buy Me a Coffee

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Nominated for 2022 - HackerNoon Contributor of the Year - Quality Assurance

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - the Greatest Storyteller

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Software Engineer

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

長すぎる; 読むには

Let Your Engineers & PMs focus on Product. Apply for $50K Credits!

コードの臭い部分を見つける方法 [パート XX]: 100 に達しました!

コードの臭い部分を見つける方法 [パート XX]: 100 に達しました!

長すぎる; 読むには

Company Mentioned

@mcsee

関連ストーリー