タグ付けされた質問 「code-smell」

私はよくオンラインで質問を探しますが、多くのソリューションには辞書が含まれています。しかし、それらを実装しようとするたびに、コードにこの恐ろしい悪臭が入ります。たとえば、値を使用するたびに： int x; if (dict.TryGetValue("key", out x)) { DoSomethingWith(x); } これは、基本的に次のことを行う4行のコードです。 DoSomethingWith(dict["key"]) outキーワードを使用すると、関数のパラメーターが変化するため、アンチパターンであると聞きました。 また、キーと値を反転させる「逆」辞書が必要になることがよくあります。 同様に、辞書の項目を繰り返し処理して、キーまたは値をリストなどに変換して、これを改善したいと思うことがよくあります。 辞書を使用するより良い、よりエレガントな方法はほとんど常にあるように感じますが、私は途方に暮れています。

19 c#  anti-patterns  code-smell  dictionary  out-parameters 

私は本当に単体テストとTDDに夢中になりました-私はテストに感染しています。 ただし、ユニットテストは通常​​、パブリックメソッドに使用されます。ただし、プライベートメソッドでもいくつかの仮定（アサーション）をテストする必要がある場合があります。これは、それらの一部が "危険"であり、リファクタリングがそれ以上役に立たないためです。（フレームワークをテストすることでプライベートメソッドをテストできることはわかっています）。 したがって、プライベートメソッドの最初の行と最後の行の両方がアサーションであることが私の習慣になりました。 ただし、パブリックメソッド（およびプライベートメソッド）でアサーションを使用する傾向があることに注意してください。パブリックメソッドの前提条件は、ユニットテストフレームワークによって外部からテストされるため、これは「テストの重複」でしょうか。 誰かがあまりにも多くのアサーションをコードの匂いだと考えることはできますか？

19 testing  code-quality  tdd  code-smell  assertions 

一緒に仕事をしている優秀な開発者が、私たちが継承したコードに機能を実装するのに苦労したことを最近教えてくれました。彼は、問題はコードを追跡するのが難しいということだと言いました。そのことから、私は製品をより深く見て、コードパスを確認することがどれほど難しいかを理解しました。 非常に多くのインターフェースと抽象レイヤーを使用していたため、物事の始まりと終わりを理解しようとするのは非常に困難でした。私は過去のプロジェクト（きれいなコードの原則に気付く前に）を見ていた時間について考えさせられ、主にコードナビゲーションツールが常にインターフェイスに到達するため、プロジェクトを回避することは非常に困難であることがわかりました。具体的な実装や、プラグインタイプのアーキテクチャで何かが接続されている場所を見つけるには、さらに多くの労力が必要です。 この理由から、一部の開発者は依存性注入コンテナを厳密に拒否しています。ソフトウェアのパスを非常に混乱させるため、コードナビゲーションの難易度は指数関数的に増加します。 私の質問は次のとおりです。フレームワークまたはパターンがこのように多くのオーバーヘッドを導入する場合、それは価値がありますか？実装パターンが不十分な場合の症状ですか？ 開発者は、フラストレーションを乗り越えるために、抽象化がプロジェクトにもたらすものの全体像を調べる必要があると思います。しかし、通常、彼らにその全体像を見せることは困難です。IOCとDIのニーズをTDDで販売できなかったことを知っています。これらの開発者にとって、これらのツールを使用すると、コードの可読性が非常に低下します。

19 testing  code-quality  tdd  code-smell  dependency-injection 

この記事では、データクラスは「コード臭」であると主張しています。理由： 新しく作成されたクラスに含まれるパブリックフィールドが少数（そしておそらく少数のゲッター/セッターさえ）である場合、これは通常のことです。しかし、オブジェクトの真の力は、データに動作タイプまたは操作を含めることができることです。 オブジェクトにデータのみが含まれているのはなぜ間違っているのですか？クラスの中心的な責任がデータを表すことである場合、データを操作するメソッドを追加して単一責任原則を破らないでしょうか？

18 data-structures  code-smell 

Martin FowlerのRefactoring bookで一般的なコードのにおいについて読んでいます。その文脈で、私はコードベースで見ているパターンについて疑問に思っていました、そしてそれが客観的にそれをアンチパターンと考えることができるかどうか。 パターンは、オブジェクトが1つ以上のメソッドへの引数として渡されるものであり、それらはすべてオブジェクトの状態を変更しますが、いずれもオブジェクトを返しません。そのため、（この場合は）C＃/。NETの参照によるパスに依存しています。 var something = new Thing(); // ... Foo(something); int result = Bar(something, 42); Baz(something); （特にメソッドに適切な名前が付けられていない場合）そのようなメソッドを調べて、オブジェクトの状態が変化したかどうかを理解する必要があることがわかりました。複数レベルの呼び出しスタックを追跡する必要があるため、コードの理解がより複雑になります。 このようなコードを改善して、新しい状態の別の（クローンされた）オブジェクト、または呼び出しサイトでオブジェクトを変更するために必要なものを返すことを提案したいと思います。 var something1 = new Thing(); // ... // Let's return a new instance of Thing var something2 = Foo(something1); // Let's use out param to 'return' other info about the …

17 code-smell  anti-patterns  parameters 

Linq To SQLをラップするデータレイヤーがあります。このデータレイヤーには、このメソッドがあります（簡略化されています） int InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); return report.ID; } 変更を送信すると、レポートIDがデータベース内の値で更新され、その値が返されます。 呼び出し側からは、次のようになります（簡略化） var report = new Report(); DataLayer.InsertReport(report); // Do something with report.ID コードを見ると、IDはInsertReport関数内で一種の副作用として設定されているため、戻り値を無視しています。 私の質問は、副作用に頼って、代わりにこのようなことをするべきかということです。 void InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); } またはそれを防ぐ必要があります int InsertReport(Report report) { var newReport = report.Clone(); db.Reports.InsertOnSubmit(newReport); db.SubmitChanges(); return newReport.ID; } たぶん Report …

17 design  code-quality  code-smell 

「高度に結合された」という用語はよく知っていますが、コードが高度に結合されていることを示す兆候（コードのにおい）があるかどうかは興味があります。現在、Java EEを使用していますが、これはどの言語にも適用できます。 編集： 誰もが興味を持っている場合、この記事は参考になります。（IBM）

16 architecture  code-smell 

IReaderインターフェイス、IReaderインターフェイスReaderImplementationの実装、およびリーダーからのデータを消費して処理するクラスReaderConsumerを想定しています。 public interface IReader { object Read() } 実装 public class ReaderImplementation { ... public object Read() { ... } } 消費者： public class ReaderConsumer() { public string location // constructor public ReaderConsumer() { ... } // read some data public object ReadData() { IReader reader = new ReaderImplementation(this.location) data …

15 mocking  code-smell 

私は「並列配列」またはリストと呼んでいるものを使用するコード（新しいコード）を実行しています。つまり、関連データを含む2つの配列があり、配列内の位置（インデックス）によってリンクされています。 私はこれを混乱させ、あらゆる種類のエラーを起こしやすいと考えています。私が通常提案する解決策は、CompanyCompanyIdおよびCompanyNameフィールドで呼び出されるオブジェクトを作成することです。 非常に現実的な例： List<string> companyNames; List<int> companyIds; //...They get populated somewhere and we then process for(var i=0; i<companyNames.Count; i++) { UpdateCompanyName(companyIds[i],companyNames[i]); } これらの並列配列は悪い習慣と見なされていますか？

14 object-oriented  programming-practices  code-smell 

私は数年前からプログラミングを行ってきましたが、C＃とJavaScriptに非常に慣れてきました。大規模なC＃およびJavaScriptプロジェクトがいくつかありますが、問題なくナビゲートできます。私は最近、PHPの経験がなくても作業するためにPHPとAngularJSプロジェクトを開始しました。 物事のPHP側の流れを追跡するのが難しくなりつつあります（JavaScript側は大きくなりますが、簡単に処理できます）。私が始めたときに犯した主要な設計ミスは山積みになり始め、今後の設計に影響を与えています。新しいものを実装するには、ますます時間がかかります。 私は締め切りが厳しく、良い、乾いた、固い、コードを書くのがますます難しくなっています。コードのチャンクをコピー/貼り付けして、設計時間が長くなるにつれてその動作にわずかな変化を加えることがより魅力的になっています。また、コンテキスト切り替えを行う必要があるときはいつでもコードベースに戻るのに時間がかかります（あるプロジェクトからこのプロジェクトに戻る）。このプロジェクトに戻るときはいつでも恐怖を感じます。 これを解決するためにどのような手順を実行できますか？上司は開発者ではなく、開発やソフトウェアのライフサイクルに精通していないため、時間がかかる可能性があることも正当化する必要があります。そのため、説明は通常より難しい場合があります。

14 php  javascript  web-applications  code-smell  technical-debt 

次のようなコードがたくさんあるコードベースを継承しました。 SomeDataAdapter sda = new SomeDataAdapter(); sda.UpdateData(DataTable updateData); そして、sdaは二度と使用されません。 これらのメソッドは、実際には静的クラスメソッドである必要があることを示すコードの匂いですか？

14 code-smell  static-methods 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私は時々、実際には他の場所に属していないように見えるメソッドと値を保持するのに役立つ「Util」クラスを作成します。しかし、これらのクラスの1つを作成するたびに、「あー、これを後悔するつもりだ...」と思うのは、どこかで悪いことを読んだからです。 しかし、他方では、2つの説得力のある（少なくとも私にとって）ケースがあるようです。 パッケージ内の複数のクラスで使用される実装の秘密 インターフェイスを乱雑にすることなく、クラスを増強するための便利な機能を提供します 私は破壊に向かっていますか？あなたが言うこと ！！リファクタリングする必要がありますか？

14 design  object-oriented  code-smell 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 誇りに思っているものがいくつかありましたが、そのうちのいくつかは数年前に自分で書いたものです。必ずしもバグがある必要はなく、単に悪いコードです。

14 code-quality  bug  code-smell 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私のコードでは、コンストラクターのパラメーターリストを介して、多くのクラスにロガーを挿入しています ランダムに配置していることに気付きました。リストの最初に表示される場合もあれば、最後に表示される場合もあります。 好みはありますか？私の直感では、一貫性はこの場合に役立ち、私の個人的な好みはそれを最初に置くことです。

12 object-oriented  code-smell  coding-style 

この質問の焦点：一部のソフトウェアは「余分な作業」を実行して、ソフトウェア内の1つまたは複数の内部エラーにもかかわらず「最終的に成功/満足」の結果を得る機会を増やします。結果が成功した場合、これらはすべてユーザーの知らないうちに発生します。 複雑なソフトウェアの定義： 存続期間中に10人以上の開発者によって作成（提供）されたコードが含まれており、同じ時間枠で記述されていない それぞれに注意事項がある10以上の外部ライブラリに依存 典型的なソフトウェアタスク（ユーザーが望む結果を生成するため）には10個以上の入力パラメーターが必要です。それらのほとんどはデフォルト値を持ちますが、ユーザーが制御を必要とする場合は構成可能です。 最も重要なことは、実行されるタスクに関連して適切な複雑さを持つソフトウェア、つまり不必要に複雑にならないソフトウェアです。 編集：複雑なものは何ですか？ComplexとComplicatedには大きな違いがあります。をご覧ください。（直接リンク） この質問内の冗長性/堅牢性の定義：（コメントに基づいて堅牢性を追加） 現在のパラメーターセットを使用したときにソフトウェアタスクが失敗した場合は、別のパラメーターを試してください。 明らかに、これらの「異なる」パラメータは異なるコードパスを使用し、結果として異なる（できればより良い）結果をもたらす可能性があるという内部知識が必要です。 これらの異なるコードパスは、外部ライブラリの観察に基づいて選択される場合があります。 最後に、実行される実際のタスクがユーザーの仕様とわずかに異なる場合、ユーザーは不一致の詳細を示すレポートを受け取ります。 最後に、10以上の構成可能なパラメーターと同様に、冗長性とレポートも構成可能です。 そのようなソフトウェアの例： データベース移行 ビジネスデータベース ソース管理データベースなど Word文書とOpenOffice文書、PowerPointおよびOpenOffice Drawなどの間のバッチ変換 ウェブサイト全体の自動翻訳 Doxygenなどのソフトウェアパッケージの自動分析。ただし、分析をより信頼性の高いものにする必要がある場合（つまり、単なるドキュメンテーションツールではない） パケットが失われる可能性があり、多くの再試行が予想されるネットワーク通信 この質問はもともと、意図的に悪いコードにどのように対処しますか？しかし、現在はソフトウェアの肥大化の原因の1つに焦点を当てています。この質問は、新機能の追加など、ソフトウェアの膨張のその他の原因には対応していません。 おそらく関連する： （巨大な）プロジェクトで複雑なコードを処理する方法 人々はどのようにして非常に複雑で読みにくいコードを書いて維持するのですか？

12 performance  exceptions  code-smell  complexity  workaround