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

Clean Codeという本を読みましたRobert C. Martinによる。この本では、小さな関数の作成、名前の慎重な選択など、コードをクリーンアップするための多くの方法を見てきました。しかし、今日、上司はこの本を読んだ後のコードの書き方が好きではありませんでした。 彼の議論は 小さな関数を書くと、コードが何をしているのかを見るために各小さな関数に移動しなければならないので苦痛です。 メインループが300行を超える場合でも、すべてをメインの大きなループに入れると、読みやすくなります。 コードを複製する必要がある場合にのみ、小さな関数を作成してください。 コメントの名前を使用して関数を記述しないでください。上記のコメントを使用して複雑なコード行（3〜4行）を入力してください。同様に、失敗したコードを直接変更できます これは私が読んだすべてのものに反しています。通常、どのようにコードを記述しますか？1つの大きなループ、小さな関数はありませんか？ 私が使用する言語は主にJavascriptです。明確に名前が付けられた小さな関数をすべて削除し、すべてを大きなループに入れたので、今は本当に読みにくいです。しかし、上司はこの方法が好きです。 一例は次のとおりです。 // The way I would write it if (isApplicationInProduction(headers)) { phoneNumber = headers.resourceId; } else { phoneNumber = DEV_PHONE_NUMBER; } function isApplicationInProduction(headers) { return _.has(headers, 'resourceId'); } // The way he would write it // Take the right …

209 design-patterns  refactoring  clean-code  functions 

私は大規模なプロジェクトを実際に書いていません。私は巨大なデータベースを維持したり、何百万行ものコードを扱ったりしていません。 私のコードは、主に「スクリプト」タイプのもの-数学関数をテストするためのもの、または何かをシミュレートするためのもの-「科学プログラミング」です。ここまでに取り組んだ最長のプログラムは数百行のコードであり、私が取り組んでいるプログラムのほとんどは約150行です。 私のコードもがらくたです。先日私が書いたファイルを見つけようとしていたので、これに気づきましたが、おそらく私は上書きしており、バージョン管理を使用していないことを知っています。これはおそらく私の愚かさに多くの人が苦しんでいます。 私のコードのスタイルは複雑で、何かを行う別の方法を記した古いコメントや、コピーされたコード行で満たされています。変数名は常に非常にわかりやすく説明的に始まりますが、たとえば、誰かがテストしたい新しいものを追加または変更すると、コードが上にオーバーレイされて上書きされます。このことをすぐにテストする必要があると思うので、私は安っぽい変数名を使用し始め、ファイルがポットに行くフレームワークを持っています。 私が現在取り組んでいるプロジェクトでは、私はこれらすべてが私に大きな意味で噛み付いてくる段階にあります。しかし、問題は（バージョン管理を使用し、新しい反復ごとに新しいファイルを作成し、そのすべてをどこかにテキストファイルに記録することを除いて、状況を劇的に改善する可能性があります）私の実際のコーディングスタイル。 より小さなコードを書くために単体テストは必要ですか？OOPはどうですか？大規模なプロジェクトで作業するのではなく、「科学的プログラミング」を行うときに、適切でクリーンなコードを迅速に記述するのにどのようなアプローチが適していますか？ 多くの場合、プログラミング自体はそれほど複雑ではないため、これらの質問をします。私がプログラミングでテストまたは研究しているのは、数学または科学に関するものです。たとえば、2つの変数と関数がおそらくそれを処理できる場合、クラスは必要ですか？（これらは一般に、プログラムの速度が速いほうが望ましい状況であると考えてください-シミュレーションの25,000,000以上のタイムステップを実行しているとき、それを望んでいます。） おそらくこれは広すぎるので、もしそうなら、私は謝罪しますが、プログラミングの本を見ると、しばしばより大きなプロジェクトで対処されているようです。私のコードはOOPを必要とせず、すでにかなり短いので、「ああ、でもそうすればファイルは1000行減ります！」これらの小さくて高速なプロジェクトで「やり直す」方法ときれいにプログラムする方法を知りたいです。 私はもっ​​と具体的な詳細を提供したいのですが、アドバイスがより一般的であればあるほど、役に立つと思います。Python 3でプログラミングしています。 誰かが重複を提案しました。標準のプログラミング標準を完全に無視することについては話していないことを明確にしましょう。明らかに、これらの標準が存在する理由があります。しかし、一方で、いくつかの標準的なことを実行できたときにOOPと呼ばれるコードを書くことは本当に意味がありますか？プログラム？ 例外があります。さらに、科学的なプログラミングには、単なる標準を超えた標準がおそらくあります。私もそれらについて尋ねています。これは、科学的なコードを書くときに通常のコーディング標準を無視すべきかどうかではなく、きれいな科学的なコードを書くことです！ 更新 「まったく1週間後ではない」種類の更新プログラムを追加すると思いました。あなたのアドバイスはすべてとても役に立ちました。現在、バージョン管理を使用しています-git、グラフィカルインターフェイス用のgit kraken。非常に使いやすく、ファイルを大幅にクリーンアップしました。古いファイルを残したり、「念のため」に古いバージョンのコードをコメントアウトしたりする必要はもうありません。 また、pylintをインストールし、すべてのコードで実行しました。最初に1つのファイルが負のスコアを獲得しました。それがどのように可能だったのかさえ私には分かりません。私のメインファイルは、〜1.83 / 10のスコアから始まり、〜9.1 / 10になりました。すべてのコードは現在、標準にかなり準拠しています。また、自分の目で行った変数名を更新しました。 特に、私はこのサイトで最近の質問をして、私の主な機能の1つをリファクタリングしました。そして今ではずっときれいで短くなっています。サイズと何が起こっているかを把握するのがはるかに簡単です。 次のステップは、ある種の「単体テスト」を実装することです。つまり、メインファイルで実行できるファイルで、アサートステートメントとtry / exceptsを使用して、その中のすべての関数を調べます。これはおそらく最善の方法ではなく、多くの重複したコードになります。しかし、私は読み続けて、それをより良くする方法を見つけようとします。 また、すでに作成したドキュメントを大幅に更新し、Excelスプレッドシート、ドキュメント、関連するペーパーなどの補足ファイルをgithubリポジトリに追加しました。それは今や本当のプログラミングプロジェクトのように見えます。 だから...私はこれがすべてだと思います：ありがとう。

169 python  coding-style  clean-code  python-3.x 

クリーンコードでは、「書式設定」の章の「垂直距離」セクションで保護された変数を避けることを推奨しています。 密接に関連する概念は、垂直方向に互いに近づける必要があります。明らかに、このルールは別々のファイルに属する概念には機能しません。ただし、非常に適切な理由がない限り、密接に関連する概念を別のファイルに分割しないでください。実際、これは保護された変数を避けるべき理由の1つです。 理由は何ですか？

168 code-quality  clean-code  variables 

私は家で自分のビジネスを気にしていると私の妻は私に来て、言う Honey ..コンソールで2018年の世界中の夏時間をすべて印刷できますか？何か確認する必要があります。 そして、Javaの経験で生涯待っていたものが次のように思いついたので、とても幸せです。 import java.time.*; import java.util.Set; class App { void dayLightSavings() { final Set<String> availableZoneIds = ZoneId.getAvailableZoneIds(); availableZoneIds.forEach( zoneId -> { LocalDateTime dateTime = LocalDateTime.of( LocalDate.of(2018, 1, 1), LocalTime.of(0, 0, 0) ); ZonedDateTime now = ZonedDateTime.of(dateTime, ZoneId.of(zoneId)); while (2018 == now.getYear()) { int hour = now.getHour(); now = …

133 design  programming-practices  clean-code 

余分に見えるコードを見つけましたが、コンパイラーはそれに気付きません。このコードを削除してもリグレッションが発生しないことを確認する（またはできる限り確実に近くする）ために何をしますか。 2つのアイデアが思い浮かびます。 「単純に」、コードが実行されるように見えるかどうかに基づいて演deを使用します。ただし、これは複雑で時間のかかる作業であり、実質的なビジネスリターンが得られないため、わずかにリスクが高い（評価がエラーになりやすい）場合があります。 そのコードセクションにロギングを配置し、実際に入力される頻度を確認します。十分な実行後、コードを削除しても安全であると合理的に確信できます。 より良いアイデアや標準的なアプローチのようなものはありますか？

125 clean-code 

私は中規模（10万行）のコードベースに取り組んでいます。それはすべて比較的新しいコード（1年未満）であり、ユニットテストのカバレッジが良好です。 どこでも使用されなくなったメソッドや、特定のメソッドのみをテストする単体テストでのみ参照されているメソッドに出くわします。 不要になったことが確実な場合、このコードを削除する必要がありますか？ 削除する理由： 少ないコード、少ないバグ 他の人にとってはコードが少ないほど消化しやすい まだソース管理下にあります 維持する理由： 参照として使用できます いつか役に立つかもしれません クラスの機能を「概算」するために作成された可能性があります

118 refactoring  clean-code 

モデレーターノート この質問には、すでに17の回答が投稿されています。新しい回答を投稿する前に、既存の回答を読んで、あなたの視点が十分にカバーされていないことを確認してください。 私はRobert Martinの「Clean Code」の本で推奨されているプラ​​クティスのいくつか、特に私が扱うソフトウェアのタイプに当てはまるものと私にとって意味のあるものに従っています（ドグマとしては従いません） 。 しかし、私が気づいた副作用の1つは、私が書いた「クリーンな」コードは、いくつかのプラクティスに従わなかった場合よりも多くのコードであるということです。これにつながる具体的なプラクティスは次のとおりです。 条件のカプセル化 の代わりに if(contact.email != null && contact.emails.contains('@') このような小さなメソッドを書くことができます private Boolean isEmailValid(String email){...} インラインコメントを別のプライベートメソッドに置き換え、メソッド名がその上にインラインコメントを持たずにそれ自体を説明するようにする クラスに変更する理由は1つだけです 他にもいくつかあります。ポイントは、コメントを置換し、条件をカプセル化する小さなメソッドなどのために、30行のメソッドになる可能性があるものがクラスになることです。あなたが非常に多くのメソッドを持っていることに気付いたとき、それは「理にかなっています」本当にメソッドでなければならないのに、すべての機能を1つのクラスに入れます。 私は、極度に行われたいかなる行為も有害である可能性があることを知っています。 私が答えを探している具体的な質問は次のとおりです。 これは、クリーンなコードを書くことの許容可能な副産物ですか？もしそうなら、より多くのLOCが書かれているという事実を正当化するために使用できるいくつかの引数は何ですか？ 組織はLOCの増加を特に懸念していませんが、LOCを増やすとクラスが非常に大きくなる可能性があります（これも読みやすいように、1回限りのヘルパー関数を使用せずに長いメソッドに置き換えることができます）。 十分な大きさのクラスを見ると、クラスが十分に忙しく、その責任が終了したという印象を与えます。したがって、他の機能を実現するために、さらにクラスを作成することになります。その結果、多数のクラスが作成され、すべてが多くの小さなヘルパーメソッドを使用して「1つのこと」を実行します。 これは特定の懸念事項です...これらのクラスは、多くの小さなメソッドの助けを借りずに、「1つのこと」を達成する単一のクラスである可能性があります。おそらく3つまたは4つのメソッドといくつかのコメントを持つ単一のクラスである可能性があります。

106 object-oriented-design  clean-code 

最近のバグ修正では、他のチームメンバーによって記述されたコードを調べる必要がありましたが、そこで見つけました（C＃です）。 return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0; さて、これらすべてのキャストに正当な理由があるので、これを理解するのは非常に難しいようです。計算に小さなバグがあり、問題を解決するためにそれを解く必要がありました。 私はこの人のコーディングスタイルをコードレビューから知っていますが、彼のアプローチは、短い方が常に良いということです。そしてもちろん、そこには価値があります。私たちはすべて、適切に配置されたいくつかの演算子で整理できる条件ロジックの不必要に複雑なチェーンを見てきました。しかし、彼は明らかに、私よりも単一のステートメントに詰め込まれた一連の演算子に精通しています。 もちろん、これは最終的にはスタイルの問題です。しかし、コードを簡潔にするための努力が役に立たなくなり、理解の障壁となる点を認識することに関して何か書いたり、研究したりしましたか？ キャストの理由はEntity Frameworkです。データベースはこれらをnull許容型として保存する必要があります。小数？C＃のDecimalとは異なり、キャストする必要があります。

102 c#  coding-style  code-quality  clean-code 

依存性注入を使用する理由についてリソースを探すのに苦労しています。私が見るほとんどのリソースは、オブジェクトのインスタンスをオブジェクトの別のインスタンスに渡すだけであると説明していますが、なぜですか？これはアーキテクチャ/コードをきれいにするためだけですか、それとも全体としてパフォーマンスに影響しますか？ なぜ次のことを行う必要があるのですか？ class Profile { public function deactivateProfile(Setting $setting) { $setting->isActive = false; } } 次の代わりに？ class Profile { public function deactivateProfile() { $setting = new Setting(); $setting->isActive = false; } }

95 architecture  object-oriented-design  clean-code 

コメントに関して、新しい同僚と議論をしています。私たちはどちらもClean Codeが好きで、インラインコードのコメントを避け、クラスとメソッドの名前を使用してそれらの動作を表現する必要があるという事実にまったく問題ありません。 ただし、主に単一の責任原則パターンを維持しやすいように、クラスの目的と実際に何が表されているのかを説明しようとする小さなクラスの要約を追加するのが大好きです。また、メソッドが何をすべきかを説明する1行の要約をメソッドに追加することにも慣れています。典型的な例は簡単な方法です public Product GetById(int productId) {...} 私は次のメソッドの概要を追加しています /// <summary> /// Retrieves a product by its id, returns null if no product was found. /// </summary メソッドがnullを返すという事実は文書化されるべきだと思います。メソッドを呼び出したい開発者は、メソッドがnullを返すか例外をスローするかどうかを確認するためにコードを開く必要はありません。インターフェースの一部であることがあるため、開発者はどのコードが実行されているのかさえ知りませんか？ しかし、私の同僚は、これらの種類のコメントは「コード臭」であり、「コメントは常に失敗」であると考えています（Robert C. Martin）。 コメントを追加せずに、これらの種類の知識を表現および伝達する方法はありますか？私はロバートC.マーティンの大ファンなので、少し混乱しています。要約はコメントと同じであるため、常に失敗しますか？ これはインラインコメントについての質問ではありません。

83 comments  clean-code 

私はまだ高品質のコードを書くには経験が浅いので、Robert C. MartinによるClean Codeなどの問題に対処する本を読み、よく知られているライブラリのコードをチェックしてスキルを向上させます。 多くのオープンソースライブラリは長年にわたって維持されていますが、正しいパスにないことはほとんどありませんが、それらの多くのコードは、クリーンなコードを記述するための原則からはほど遠いことがわかりました。数百行のコード。 だから私の質問は次のとおりです。きれいなコードの原則はあまりにも制限されていますか？そうでない場合、これらの原則の多くを考慮せずに巨大なライブラリをどのように維持していますか？ 簡単な説明をいただければ幸いです。質問が初心者の人からばかげていると思われる場合、私は謝罪します。 編集 Butterknifeライブラリでこの例を確認してください。Androidコミュニティで最もよく知られているライブラリの1つです。

80 architecture  code-quality  libraries  clean-code  code-reuse 

私のチームでは、大きなモノリシックプロジェクト（クラス全体、メソッドなど）で多くの古いものを削除しています。 そのクリーニングタスクの間に、私はいつもよりも一種の注釈やライブラリの凝ったものがあるのか​​と思っていました@Deprecated。これにより@FancyDeprecated、特定の日付が過ぎた後に古い未使用コードをクリーンアップしていない場合、プロジェクトのビルドが成功しなくなります。 インターネットで検索してみましたが、以下に説明する機能を持つものは見つかりませんでした。 特定の日付の前に削除する予定のコードに配置するための注釈または類似のもの その日付の前にコードがコンパイルされ、すべてが正常に動作します その日以降、コードはコンパイルされず、問題について警告するメッセージが表示されます 私はユニコーンを探していると思います...どのプログラム言語にも同様の技術はありますか？ 計画として、BIは、「デッドライン」で失敗し始めるコードの単体テストでマジックを作成する可能性を考えています。これについてどう思う？より良いアイデアはありますか？

68 code-quality  clean-code  deprecation  deadlines 

Clean Codeの名前に関するボブおじさんの章では、主にハンガリーの表記法に関して、名前のエンコーディングを避けることを推奨しています。またI、インターフェイスからプレフィックスを削除することについて具体的に言及していますが、この例は示していません。 以下を想定してみましょう： インターフェイスの使用法は、主に依存性注入によりテスト容易性を実現することです 多くの場合、これは単一の実装者と単一のインターフェースを持つことにつながります それで、例えば、これらの2つは何と命名されるべきでしょうか？ParserそしてConcreteParser？ParserそしてParserImplementation？ public interface IParser { string Parse(string content); string Parse(FileInfo path); } public class Parser : IParser { // Implementations } または、このような単一実装の場合、この提案を無視する必要がありますか？

68 c#  naming  clean-code  naming-standards 

しばしば、私のようなホットネットワークの質問リスト上の質問を参照、この基本的には「私はCSSでこの任意の形状を描くんか」尋ねます。常に答えは、要求された形状を形成する一見ランダムにハードコードされた値の束を持つCSSまたはSVGデータのブロックです。 これを見ると、「うん！なんとcodeいコードブロックです。私のプロジェクトでこの種のものを見ないことを願っています。」しかし、私はこれらのタイプのQ＆Aを非常に頻繁に、多数の賛成票で見ているので、明らかにコミュニティはそれらが悪いとは思わない。 しかし、なぜこれが受け入れられるのでしょうか？私のバックエンドの経験から来ると、これは私には意味がありません。では、なぜCSS / SVGで問題ないのでしょうか？

63 coding-style  code-quality  css  clean-code  svg 

プログラム（iOSアプリ）には3つのビューがあります。一度にアクティブになるのはそのうちの1つだけなので、そのうち2つに対して可視性をオフに設定し、ユーザーがボタンを押したときに可視性を切り替えます。ビューは可視として初期化されるため、メインビューが表示される前にコードで可視性をオフに設定します。 できます [view1 setAlpha:0.0f]; [view2 setAlpha:0.0f]; 2つのビューについてですが、現在は3番目のビュー（アプリの起動時に表示されるはずのビュー）には対応していません。私は [view3 setAlpha:1.0f]; 最初の2つの後、実際には3つのビューがあり、コードを見たときに考えられる2つではないことを明確に保つためだと思います。他のプログラマはどのようにこれを行いますか？それは純粋に好みですか、またはいくつかの規則がありますか？ 呼び出しが非常に重い場合は、それが必要でないときに呼び出しを行わない方が明らかに良いですが、私の例のような小さなことについて疑問に思っていました。

60 coding-style  clean-code