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

C＃では、#region/ #endregionキーワードを使用して、エディターでコードの領域を折りたたみ可能にすることができます。これを行うたびに、おそらく他のクラスやメソッドにリファクタリングされる可能性のある大きなコードの塊を隠すためにそれを行います。たとえば、管理しやすくするために、3つまたは4つの領域を持つ500行のコードを含むメソッドを見てきました。 地域の賢明な使用は問題の兆候でしょうか？私にはそう思われます。

265 c#  code-smell 

私がしばらく知っているが、考慮されていないことは、ほとんどの言語では、順序に基づいてifステートメントで演算子を優先することができるということです。私はよく、これをヌル参照例外を防ぐ方法として使用します。例えば： if (smartphone != null && smartphone.GetSignal() > 50) { // Do stuff } この場合、コードは最初にオブジェクトがnullでないことを確認し、次にこのオブジェクトが存在することを知って使用します。言語が賢いのは、最初のステートメントがfalseの場合、2番目のステートメントを評価しても意味がないため、null参照例外がスローされないことがわかっているためです。これはandand or演算子でも同じように機能します。 これは、インデックスが配列の境界内にあることを確認するなど、Java、C＃、C ++、Python、Matlabなどのさまざまな言語でこのような手法を実行できるなど、他の状況でも役立ちます。 私の質問は次のとおりです。この種のコードは悪い習慣を表していますか？この悪い習慣は、隠れた技術的な問題から生じますか（つまり、最終的にエラーになる可能性があります）、または他のプログラマーにとって読みやすさの問題につながりますか？紛らわしいですか？

88 programming-practices  language-agnostic  code-smell  operators 

s で新しいトリックを披露したり、3つの異なる手順を一般化したりする必要があるときの気持ちを知っていExpressionますか？これはArchitecture Astronautの規模である必要はなく、実際に役立つかもしれませんが、他の誰かが同じクラスまたはパッケージをより明確で率直な（そして時には退屈な）方法で実装することに気づかずにはいられません。 私はしばしば問題を過剰に解決することによってプログラムを設計することに気づきました。時には故意に、時には退屈から。どちらの場合でも、反対の証拠を見るまで、私のソリューションは非常に透明でエレガントであると正直に信じていますが、通常は手遅れです。また、コードの重複よりも文書化されていない仮定を好み、単純さよりも賢いことを好む私もいます。 何をするために行うことができ、「cleverish」のコードを記述する衝動に抵抗してたときにベルリングをすべきであること、私はそれは間違ってやっていますか？ 私は今、経験豊富な開発者のチームと協力しているため、問題はさらに押し進められています。スマートコードを書くという私の試みは、時間が優雅さの幻想を払拭した後でも自分にとっては愚かに思えます。

75 architecture  programming-practices  language-agnostic  code-smell 

SOに関するこの質問は、OPが機能en望のコードだと考えているものを修正することについて語っています。この気の利いたフレーズが引用されているのを私が見た別の例は、ここでprogrammers.SEで最近与えられた答えです。私はその答えにコメントを入れて情報を求めましたが、Q＆Aを読んでプログラマがfeature-envyという用語の意味を理解することは一般的な助けになると思いました。適切と思われる場合は、追加のタグを自由に編集してください。

53 refactoring  code-reviews  clean-code  code-smell 

通常、コピーアンドペーストおよびその他のあらゆる悪い慣行を使用して、単体テストを一緒にスローします。通常、単体テストは非常に見苦しく、「コードのにおい」に満ちていますが、これは本当に重要ですか？「本当の」コードが「良い」ものである限り、それは重要なことです。さらに、ユニットテストでは通常、スタブ機能などのさまざまな「臭いハック」が必要です。 不十分に設計された（「臭い」）単体テストについて、どの程度心配する必要がありますか？

52 unit-testing  code-quality  code-smell 

フラグ変数は悪ですか？次の種類の変数は非常に不道徳であり、それらを使用するのは邪悪ですか？ 「特定の場所で値を割り当てた後でブール値または整数変数を下にチェックしてから、何かをするかどうかをチェックしてから、たとえばnewItem = true以下の行を使用するif (newItem ) then」 フラグの使用を完全に無視して、より良いアーキテクチャ/コードになったプロジェクトをいくつか行ったことを覚えています。しかし、それは私が働いている他のプロジェクトでは一般的な慣行であり、コードが大きくなりフラグが追加されると、IMHOコードスパゲッティも大きくなります。 フラグを使用するのが良い習慣である、あるいは必要な場合があると言いますか？またはコードでフラグを使用することは...赤いフラグであり、回避/リファクタリングする必要があることに同意しますか？私は、代わりにリアルタイムで状態をチェックする関数/メソッドを実行するだけでうまくいきます。

47 code-quality  code-smell  maintainability 

レガシーコードでは、データのラッパーにすぎないクラスが時々見られます。何かのようなもの： class Bottle { int height; int diameter; Cap capType; getters/setters, maybe a constructor } オブジェクト指向についての私の理解は、クラスはデータの構造であり、そのデータを操作する方法だということです。これは、このタイプのオブジェクトを除外するようです。私にとって、それらはstructsオブジェクト指向の目的に勝るものではありません。コードの匂いかもしれませんが、必ずしも悪いとは思いません。 そのようなオブジェクトが必要になる場合はありますか？これが頻繁に使用される場合、デザインが疑わしいですか？

43 java  code-quality  object-oriented  code-smell 

Webには、コードのにおいを参照し、リストするリソースが山ほどあります。しかし、建築の匂いに関する情報を見たことはありません。これはどこかで定義されていますか、利用可能なリストはありますか？アーキテクチャの欠陥、およびプロジェクトの速度、欠陥などへの影響について正式な調査が行われましたか？ 編集：私は本当に答えのリストを探していませんでしたが、アーキテクチャに関する臭い（ウェブ上または本）のドキュメントを探していました。

37 architecture  code-smell  quality 

たくさんの2-3k行のファイルを見つけていますが、それほど大きくはないようです。 ソースコードファイルを客観的に「大きすぎる」と呼ぶのに適した基準は何ですか？

36 code-quality  code-smell 

友人のグループと私は過去少しの間プロジェクトに取り組んでおり、私たちは私たちの製品に固有のシナリオを表現する素晴らしいOOP方法を発明したかったのです。基本的に、私たちは東方スタイルの 弾丸地獄ゲームに取り組んでおり、私たちが思いつく可能性のある弾丸のあらゆる行動を簡単に表現できるシステムを作りたかったのです。 それがまさに私たちがやったことです。Unityのコンポーネントシステムのように、弾丸の動作を自由に弾丸インスタンスにアタッチできるさまざまなコンポーネントに分割できる、非常にエレガントなアーキテクチャを作成しました。うまく機能し、簡単に拡張可能で、柔軟性があり、すべてのベースをカバーしていましたが、わずかな問題がありました。 また、アプリケーションには大量の手続き生成が含まれます。つまり、弾丸の動作を手続き的に生成します。なぜこれが問題なのですか？さて、弾丸の動作を表現するためのOOPソリューションは、エレガントではありますが、人間なしで作業するのは少し複雑です。人間は、論理的で賢い問題の解決策を考えるのに十分賢いです。手続き型生成アルゴリズムはまだそれほどスマートではなく、OOPアーキテクチャを最大限に活用するAIを実装するのは難しいことがわかりました。確かに、それはアーキテクチャの欠陥であり、すべての状況で直感的ではないということです。 したがって、この問題を解決するために、さまざまなコンポーネントによって提供されるすべての動作を基本的にbulletクラスに押し込みました。これにより、想像できるすべてが、他の関連するコンポーネントインスタンスではなく、各bulletインスタンスで直接提供されます。これにより、手続き生成アルゴリズムの操作が少し簡単になりますが、現在の弾丸クラスは巨大な神オブジェクトです。これは、他のコードの5倍以上のコードを持つ、これまでのプログラムで簡単に最大のクラスです。維持するのも少し苦痛です。 別の問題で作業しやすくするために、クラスの1つが神のオブジェクトに変わっても大丈夫ですか？一般に、別の問題に対する簡単な解決策を認めている場合、コードにコードの匂いがすることは問題ありませんか？

31 object-oriented  architecture  code-smell 

初めてPythonを使用して、同じファイルに複数のクラスを記述することになりました。これは、クラスごとに1つのファイルを使用するJavaなどの他の言語とは対照的です。 通常、これらのクラスは1つの抽象基本クラスで構成され、1-2の具体的な実装が使用されますが、使用方法はわずかに異なります。以下にそのようなファイルを1つ投稿しました。 class Logger(object): def __init__(self, path, fileName): self.logFile = open(path + '/' + filename, 'w+') self.logFile.seek(0, 2) def log(self, stringtoLog): self.logFile.write(stringToLog) def __del__(self): self.logFile.close() class TestLogger(Logger): def __init__(self, serialNumber): Logger.__init__('/tests/ModuleName', serialNumber): def readStatusLine(self): self.logFile.seek(0,0) statusLine = self.logFile.readLine() self.logFile.seek(0,2) return StatusLine def modifyStatusLine(self, newStatusLine): self.logFile.seek(0,0) self.logFile.write(newStatusLine) self.logFile.seek(0,2) class GenericLogger(Logger): def …

31 python  code-quality  code-smell 

.csファイル内に複数のクラスを作成することをお勧めしますか、それとも各.csファイルに個別のクラスが必要ですか？ 例えば： public class Items { public class Animal { } public class Person { } public class Object { } } これが良いアーキテクチャの貧弱な例であるという事実を少し避けて、.csファイルに複数のクラスがあることはコード臭いですか？

30 c#  code-smell 

これは、物議を醸すプログラミングの意見のスレッドでこの答えを読んで以来ずっと考えてきたことです。 あなたの仕事は、自分を失業させることです。 雇用主向けのソフトウェアを作成する場合、作成するソフトウェアは、開発者が理解し、最小限の労力で理解できるように作成する必要があります。適切に設計され、明確かつ一貫して記述され、きれいにフォーマットされ、必要な場所に文書化され、期待どおりに毎日ビルドされ、リポジトリにチェックインされ、適切にバージョン管理されます。 あなたがバスにぶつかったり、解雇されたり、解雇されたり、仕事を辞めたりした場合、あなたの雇用主はすぐにあなたに取って代わることができ、次の人があなたの役割に入り、あなたのコードを拾い上げて1週間以内に走ります。彼または彼女がそれを行うことができない場合、あなたは惨めに失敗しました。 興味深いことに、その目標を持っていることが雇用主にとってより価値のあるものであることがわかりました。使い捨てになるように努力すればするほど、彼らにとってより価値のあるものになります。 そして、これは他の質問、例えばこれで少し議論されましたが、私は再びそれを持ち出し、より多くの空白から「それはコードの匂いです!!」という観点から議論したかったのです。まだ深さ。 私は10年間プロの開発者です。私は、適切な新しい開発者が比較的迅速に理解できるようにコードが十分に書かれた仕事を1つ持っていますが、業界のほとんどの場合、非常に高いレベルの所有権（個人とチームの所有権の両方）が普通。ほとんどのコードベースには、新しい開発者がそれらを選択してすばやく作業できるようにするためのドキュメント、プロセス、および「オープン性」が欠けているようです。コードベースを非常によく知っている（「所有している」）誰かが知っている、書かれていない小さなトリックやハックが常にたくさんあるようです。 もちろん、これに関する明らかな問題は次のとおりです：人がやめるか、「バスにぶつかった」場合 または、チームレベルで、チームランチに出かけたときにチーム全体が食中毒になり、全員が死亡した場合はどうなりますか？チームを比較的簡単に新しいランダムな開発者の新しいセットに置き換えることができますか？-私の過去の仕事のいくつかでは、そのことがまったく想像できません。システムには非常に多くのトリックとハックがあり、「知っておく必要がある」だけなので、採用する新しいチームは収益性の高いビジネスサイクル（たとえば、新しい安定したリリース）よりもはるかに長くかかります。要するに、製品を放棄しなければならないとしても、私は驚かないでしょう。 明らかに、チーム全体を一度に失うことは非常にまれです。しかし、これにはもっと微妙で不吉なことがあると思います-これは、このスレッドでこれまで議論したのを見たことがないので、このスレッドを開始することを考えさせたポイントです。基本的に、コードの所有権に対する高いニーズは、技術的な負債の指標であることが非常に多いと思います。システムにプロセス、コミュニケーション、優れたデザイン、多くの小さなトリックやハッキングが欠けていて「知っておく必要がある」などの場合は、通常、システムが次第に深く技術的な負債に陥っていることを意味します。 ただし、コードの所有権は、プロジェクトや会社に対する一種の「忠誠心」として、またあなたの仕事に対する「責任を負う」肯定的な形として提示されることが多いため、完全に非難することは一般的ではありません。しかし同時に、方程式の技術的負債の側面は、コードベースが次第にオープンになり、作業が難しくなることを意味することがよくあります。そして、特に人々が前進し、新しい開発者がその地位に就く必要があるため、技術的な負債（つまり、メンテナンス）コストが高騰し始めます。 ですから、ある意味では、コードの所有権に対する高いレベルのニーズが、一般的なプログラマーの想像力の中で、仕事の匂いとして公然と見られていれば、私たちの職業にとって良いことだと思います。「仕事に責任と誇りを持っている」と見なされるのではなく、「技術的な負債を介して自分自身を定着させ、人工的な職の安全を確保する」と見なすべきです。 そして、テスト（思考実験）は基本的にすべきだと思います：もしその人（あるいはチーム全体）が明日地球の表面から消えたとしたら？これはプロジェクトの巨大な-おそらく致命的な-怪我になりますか、それとも新しい人々を連れて来て、彼らにdoccosとヘルプファイルを読んでもらい、数日間コードを遊んでもらうことができますか？数週間でビジネスを開始します（1か月ほどで完全な生産性に戻ります）。

27 development-process  code-quality  source-code  code-smell  code-ownership 

私たちは2010年に、4年または5年以上の経験を持つソフトウェアエンジニアであり、96のフラッキングカラムを持つテーブルを設計しています。 私は彼にそれが悪夢になると言った。 MySQLをC＃とインターフェイスするには序数を使用する必要があることを彼に示しました。 行よりも列の方が多い表は大きな臭いだと説明しました。 それでも、「この方法でもっと簡単になるだろう」というメッセージが表示されます。 私は何をすべきか？ 編集* このテーブルには、センサーからのデータが含まれます。 Dynamic_D1X Dynamic_D1Y を備えたセンサー1があります [...] Dynamic_D6X Dynamic_D6Y [...] EDIT2 * さて、私はついにその仕事を辞めました。それは、他のプログラマーが何ヶ月も暗くなったときの兆候であり、管理者がこれが問題であることを認識していないときの別の兆候です

23 sql  code-smell 

init()型のメソッドを宣言する目的はありますか？ 私はコンストラクタよりも優先init()すべきかどうか、または宣言を避ける方法をinit()尋ねていません。 メソッドを宣言する背後に何らかの理由があるのかinit()（それがどれほど一般的かを見て）、それがコードのにおいであり、避けるべきかどうかを尋ねています。 init()イディオムは非常に一般的ですが、私は、任意の真のメリットを見ていません。 メソッドによる初期化を促進する型について話している： class Demo { public void init() { //... } } これはいつプロダクションコードで使用されますか？ コンストラクターがオブジェクトを完全に初期化せず、部分的に作成されたオブジェクトを生成することを示唆しているため、コードの匂いがするかもしれません。状態が設定されていない場合、オブジェクトは存在しないはずです。 これは、エンタープライズアプリケーションの意味で、生産をスピードアップするために使用されるある種の手法の一部である可能性があると信じさせてくれます。それは私がそのようなイディオムを持つことを考えることができる唯一の論理的な理由です。

20 java  object-oriented  object-oriented-design  code-quality  code-smell