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

私はJavaでプログラミングしており、常にコンバーターを次のように作成しています。 public OtherObject MyObject2OtherObject(MyObject mo){ ... Do the conversion return otherObject; } 新しい職場でのパターンは次のとおりです。 public void MyObject2OtherObject(MyObject mo, OtherObject oo){ ... Do the conversion } 私にとっては、着信パラメータを変更しないことに慣れていたので、少し臭いです。この着信パラメータの変更はアンチパターンですか、それとも大丈夫ですか？重大な欠点がありますか？

60 java  clean-code  anti-patterns 

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

53 refactoring  code-reviews  clean-code  code-smell 

時々（まれに）、適切な量のパラメーターをとる関数を作成することが最適なルートであると思われます。しかし、そうすると、パラメーターの順序をランダムに選択することが多いように感じます。私は通常、最も重要なパラメーターを最初に使用して、「重要度の順に」進みます。 これを行うためのより良い方法はありますか？明確性を高めるパラメーターを並べる「ベストプラクティス」の方法はありますか？

52 refactoring  clean-code  functions  parameters  order 

Robert C. MartinによるClean Codeの最初の章を読みましたが、かなり良いように思えますが、疑問があるのですが、ある部分では、関数のパラメーターが少ないほど良い（認知的に）ことは言及されています可能な限り、3つ以上のパラメータが関数には大きすぎることを示唆しています（私は非常に誇張されており、理想的です）ので、私は疑問に思い始めました... グローバル変数を使用し、関数に多くの引数を渡すという慣習はどちらも悪いプログラミング慣行ですが、グローバル変数を使用すると、関数のパラメーターの数を大幅に減らすことができます... だから私はあなたがそれについて考えることを聞きたかったのですが、関数のパラメータの数を減らすためにグローバル変数を使う価値はありますか？どのような場合になりますか？ 私が思うに、それはいくつかの要因に依存しているということです： ソースコードのサイズ。 関数の平均のパラメーターの数。 関数の数。 同じ変数が使用される頻度。 私の意見では、ソースコードのサイズが比較的小さい場合（600行未満のコードなど）、多くの関数があり、同じ変数がパラメータとして渡され、関数には多くのパラメータがあり、グローバル変数を使用する価値がありますが、知りたい... 私の意見を共有しますか？ ソースコードが大きい他のケースなどについてどう思いますか？ PS。私はこの投稿を見ました、タイトルは非常に似ていますが、彼は私が知りたいことを尋ねません。

49 programming-practices  clean-code  variables  globals 

ソフトウェア開発会社の主な目標の1つは、バスファクターを増やすことです。これは、Googleが主催した講演でも支持されています。 つまり、明日バスで走り去ってもプロジェクトが継続できるように、すべてをコーディングして文書化する必要があります。言い換えれば、あなたはあなたと同じようなスキルセットを持つ他のプログラマーに簡単に交換できるようにするべきです。 交換可能であることは、開発者の利益に反するものではありませんか？この本では、48の権力法則11 で、権力を得るために人々をあなたに依存させ続け、それが金銭的な報酬に変換されるようにすべきであると述べています。 6か月の一時停止後もプロジェクトを続行するために自分用のドキュメントが必要なシナリオとは別に、開発者とソフトウェア会社の間には明確な利害の対立があるようです。 プログラマーとして、本当に素晴らしいドキュメントと誰でも簡単に読めるコードを書くべきでしょうか。または、それが仕事をし、あなた自身がそれを理解できる方法でコードとドキュメントを書くべきですが、他の人はそれを理解するのに苦労するかもしれませんか？

48 documentation  clean-code 

でクリーンなコードの作者は、例を示します assertExpectedEqualsActual(expected, actual) 対 assertEquals(expected, actual) 前者は、議論がどこに行くのか、それから生じる潜在的な誤用を覚える必要がなくなるため、より明確であると主張した。しかし、どのコードでも前者の命名スキームの例を見たことはなく、後者を常に見ています。著者が主張するように、後者が前者よりも明確であれば、なぜ前者を採用しないのですか？

47 clean-code 

ボブおじさんのきれいなコードの提案に従い、特にメソッドを短くするようにしています。 ただし、このロジックを短縮することはできません。 if (checkCondition()) {addAlert(1);} else if (checkCondition2()) {addAlert(2);} else if (checkCondition3()) {addAlert(3);} else if (checkCondition4()) {addAlert(4);} 私はelseを削除することができないため、全体を小さなビットに分割し、「else if」の「else」を使用するとパフォーマンスが向上します本当です、私はそれらを避けたいです。 意味的に言えば、前の条件が満たされた場合に次の条件を評価することは、ビジネスの観点からは意味がありません。 編集：この質問は、if（if else）elseを処理するエレガントな方法の可能な重複として識別されました。 これは別の質問だと思います（これらの質問の回答を比較することでも確認できます）。 私の質問は、すぐに終わる最初の受け入れ条件をチェックしています。 リンクされた質問は、何かをするためにすべての条件を受け入れようとしている。（この質問に対するこの回答でよく見られます：https : //softwareengineering.stackexchange.com/a/122625/96955）

45 clean-code  conditions 

バックグラウンド ： 私はAndroidアプリでボブおじさんのクリーンアーキテクチャを使用しようとしています。私はそれを行う正しい方法を示しようとしている多くのオープンソースプロジェクトを研究し、RxAndroidに基づいた興味深い実装を見つけました。 気づいたこと： すべてのレイヤー（プレゼンテーション、ドメイン、およびデータ）には、同じエンティティ（UMLを話す）のモデルクラスがあります。さらに、データが境界を越えたとき（レイヤーから別のレイヤーへ）にオブジェクトを変換するマッパークラスがあります。 質問 ： すべてのCRUD操作が必要な場合、すべてのモデルクラスが同じ属性で終わることがわかっている場合、すべてのレイヤーにモデルクラスが必要です。または、クリーンアーキテクチャを使用する場合のルールまたはベストプラクティスですか？

44 java  architecture  android  clean-code  layers 

それで、私は数年前からプログラミングをしていて、最近ReSharperをもっと使い始めました。ReSharperが私に常に示唆していることの1つは、「 'if'ステートメントを逆にして入れ子を減らす」ことです。 このコードがあるとしましょう： foreach (someObject in someObjectList) { if(someObject != null) { someOtherObject = someObject.SomeProperty; } } そして、ReSharperは私がこれを行うことを提案します： foreach (someObject in someObjectList) { if(someObject == null) continue; someOtherObject = someObject.SomeProperty; } ReSharperは、ネストがどれだけ進んでいるかに関係なく、IFを反転させることを常に提案するようです。この問題は、少なくともいくつかの状況でネストするのが好きだということです。私にとっては、特定の場所で何が起こっているのかを読み、理解するのが簡単に思えます。これは常にそうではありませんが、私は時々より快適なネストを感じます。 私の質問は、個人的な好みや読みやすさ以外に、ネストを減らす理由はありますか？パフォーマンスの違いや、私が気付いていない他の何かがありますか？

39 .net  coding-style  code-quality  clean-code  resharper 

（私は（プログラミング言語ではなく）HTML / CSSコードについて話しているが、プログラマーと同じ問題に直面していると思う。） 私はチームのシニアフロントエンドデザイナーであり、後輩の成果を厳しい締め切りで頻繁に作り直す必要があります。 私は2つの問題に直面しています： それらのコーディングスタイルは少し複雑です。 美学は良くありません。 彼らのコーディングスタイルは、適切な慣習/標準がない混合バッグです。私は、コードをクリーンアップするか、単にコードを処理する（それらがどのように動作するかをコピーする）ことで引き裂かれます。 私は悪い習慣を学ぶかもしれないと思うので、彼らのコーディングスタイルに従うのはイライラします。しかし、その後、それが期限を満たすための最速の方法です。 より多くの経験を持つ人にとって、どれがより効果的ですか？クリーンアップを後で保存する必要がありますか？または、変更の途中でクリーンアップしますか？ （私は慢に聞こえたくはありませんが、それは現実です。より良いコードを書くのに何年もかかるでしょう。

38 coding-style  html  clean-code 

ドメインエンティティを取得するビジネスロジックメソッドを提供する場合、パラメーターはオブジェクトまたはIDを受け入れる必要がありますか？たとえば、これを行う必要があります： public Foo GetItem(int id) {} またはこれ： public Foo GetItem(Foo foo) {} オブジェクト全体を渡すことをお勧めしますが、オブジェクトを取得し、IDのみを知っているこの場合はどうでしょうか？呼び出し元は空のFooを作成してIDを設定する必要がありますか、それともメソッドにIDを渡すだけですか？IDを除いて、着信Fooは空になるため、GetItem（）メソッドにIDを送信するだけでFooを作成し、IDを設定する必要があるという呼び出し側の利点はありません。

38 c#  design  object-oriented  clean-code 

ときどき、コードを「きれいに」見えるようにすることに苦労してばかげた時間（時間）を費やします。私は物事を対称的に見せることを意味します。実際にクラス全体をすばやくスクロールして、「きれい」または「きれい」に見えないものが飛び出すかどうかを確認します。 時間を無駄にしていますか？この種の動作には何か価値がありますか？コードの機能やデザインが変更されないこともあるので、見た目が良くなるように再構築します。 私は完全にOCDなのでしょうか、またはこれにいくつかの利点が隠されていますか？

34 clean-code 

コンテキスト できれいなコード、35ページ、それは言います これは、ifステートメント、elseステートメント、whileステートメントなど内のブロックが1行の長さであることを意味します。おそらくその行は関数呼び出しであるべきです。これにより、囲んでいる関数が小さく保たれるだけでなく、ブロック内で呼び出される関数にわかりやすい名前を付けることができるため、ドキュメントの価値も高まります。 私は完全に同意します、それはとても理にかなっています。 後で40ページで、関数の引数について説明します 関数の理想的な引数の数はゼロ（niladic）です。次に1つ（単項）、2つ（2項）が続きます。可能な場合は、3つの引数（3項）を避ける必要があります。3つ以上（ポリアディック）には非常に特別な正当化が必要です。引数は難しいです。彼らは多くの概念的な力を取ります。 私は完全に同意します、それはとても理にかなっています。 問題 しかし、しばしば私は別のリストからリストを作成していることに気づき、2つの悪の1つと一緒に暮らさなければなりません。 ブロック内で2つの行を使用します。1つは物を作成するため、もう1つは結果に追加するためです。 public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms) { List<Flurp> flurps = new List<Flurp>(); foreach (BadaBoom badaBoom in badaBooms) { Flurp flurp = CreateFlurp(badaBoom); flurps.Add(flurp); } return flurps; } または、事物が追加されるリストの関数に引数を追加し、「1つの引数が悪化する」ようにします。 public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms) { List<Flurp> flurps = new List<Flurp>(); foreach (BadaBoom badaBoom in …

33 clean-code  solid 

私はかなり大きなコードベースに取り組んでいます。数百のクラス、大量の異なるファイル、多くの機能が、新しいコピーの取得などに15分以上かかります。 このような大きなコードベースの大きな問題は、かなりの数のユーティリティメソッドがあり、同じことを行うか、可能な場合にこれらのユーティリティメソッドを使用しないコードがあることです。また、ユーティリティメソッドは、すべてが1つのクラスに含まれているわけではありません（巨大な混乱のせいだからです）。 私はコードベースにはかなり慣れていませんが、何年もこのコードに取り組んでいるチームリーダーも同じ問題を抱えているようです。それは多くのコードと作業の重複につながり、そのため、何かが壊れると、通常は基本的に同じコードの4つのコピーで壊れます このパターンをどのように抑制できますか？ほとんどの大規模プロジェクトと同様に、すべてのコードが文書化されているわけではありません（一部は文書化されています）。しかし、基本的には、この点で品質の改善に取り組み、将来コードの重複を減らし、ユーティリティ関数のようなものを見つけやすくすることができれば、本当に素晴らしいことです。 また、ユーティリティ関数は通常、いくつかの静的ヘルパークラス、単一のオブジェクトで動作する非静的ヘルパークラス、または主に「ヘルプ」を行うクラスの静的メソッドのいずれかにあります。 拡張メソッドとしてユーティリティ関数を追加する1つの実験がありました（クラスの内部は不要であり、非常に特定のシナリオでのみ必要でした）。これには、プライマリクラスなどが乱雑になるのを防ぐ効果がありましたが、すでにそれを知っていない限り、実際には発見できません

33 design-patterns  refactoring  clean-code 

特定の条件が満たされるまでマップを反復処理し、後でその条件を使用してその他の処理を実行するコードがあります。 例： Map<BigInteger, List<String>> map = handler.getMap(); if(map != null && !map.isEmpty()) { for (Map.Entry<BigInteger, List<String>> entry : map.entrySet()) { fillUpList(); if(list.size() > limit) { limitFlag = true; break; } } } else { logger.info("\n>>>>> \n\t 6.1 NO entries to iterate over (for given FC and target) \n"); } if(!limitFlag) …

30 design-patterns  object-oriented  object-oriented-design  clean-code