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

高品質のコードを書くためのベストプラクティスに関する質問。

16
他のブロックはコードの複雑さを増しますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 これは非常に単純化された例です。これは必ずしも言語固有の質問ではありません。関数を作成できる他の多くの方法、およびそれに加えられる変更を無視してください。。色はユニークなタイプです string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } else { return "No you can't"; } } 私が出会った多くの人々、ReSharper、およびこの男(コメントから、しばらくの間これを尋ねようとしていることを思い出した)は、コードをリファクタリングして、elseこれを残すブロックを削除することをお勧めします。 (私は大多数が言ったことを思い出せない、そうでなければ尋ねなかったかもしれない) string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } return "No you can't"; } 質問:elseブロックを含めないことで複雑さが増しますか? 私はelse、両方のブロックのコードが直接関係しているという事実を述べることにより、意図がより直接的に述べられているという印象を受けています。 さらに、特に後日コードを変更した後は、ロジックの微妙な間違いを防ぐことができます。 私の単純化された例のこのバリエーションを取り上げます(orこれは意図的に単純化された例であるため、演算子を無視します)。 bool CanLeaveWithoutUmbrella() { if(sky.Color != Color.Blue) { …

1
Jester for Javaのような突然変異テストツールの最新の代替品はありますか?
「確かにわかるのに、なぜあなたのテストは良いと思うのですか?Jesterは私のテストが気密であると言うこともありますが、見つかった変更が突然発生することもあります。強くお勧めします。」-ケントベック しかし、stackoverflowには「Jester」というタグすらありません。では、Jesterの最新の代替品はありますか?CoberturaやCloverなどのツールのコードカバレッジから統計を見つけること以外に、記述された単体テストが堅実であることをどのように確認できますか?

5
記述的な命名と80文字の行[クローズ]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 私はこれらの2つの価値あるプログラミング慣行を頻繁に耳にします。(1)コードの行は80文字以下である必要があり、(2)変数、メソッド、クラスなどにわかりやすい名前を使用します。 、彼らはしばしばお互いのトレードオフのようです。コードを80文字/行未満に保つと、よりわかりにくい名前を使用することになります(特に各インデントが4文字としてカウントされるPythonでは)が、より説明的な名前を使用すると、80文字を超える行になります。 だから、私の質問は、これらの2つのアドバイスのうち、どちらを選択する必要があるかを守ることがより重要ですか?私はこれを独立した(趣味の)プログラマーだと思っていますが、もっと重要なのは、大企業で働くソフトウェアエンジニアの観点からです。

5
関数がパラメーターを変更しても大丈夫ですか
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 …

5
存在しない場合にgetで何かを作成するのは悪いコーディング習慣ですか?
だから私はgetAccountそれがそれを取得した場合、アカウントに識別子を返すようなものを持っているウェブサービスを持っている、そうでなければ例外をスローします。クライアントは、取得と同じ情報で例外がスローされた場合、常にアカウントを作成したいと思うでしょう。 クライアント用の便利なライブラリを作成しています。このライブラリは、内部ですべてのWebサービス呼び出しを処理するため、呼び出しを自分で行う方法を知る必要はありません。 私が疑問に思っているのはgetAccount(accountName)、アカウントが存在する場合にアカウントを取得するものを作成し、それを作成して情報を返さない場合、それは悪いことですか?例外を処理するためにクライアントに任せるか、単にgetOrCreateAccountのような名前を付ける必要がありますか?それは重要ですか? get操作で何かを作成するのは悪い習慣ですか?

7
内部の代表者、投票、バッジは、優れたプログラミングの実践を促進するでしょうか?
声を出して考えてみてください-私たちのプログラマーは投票/バッジ/担当者が好きなので、このようなスキームを企業のコードレビュープロセスに導入して、より良いコーディングを奨励できます。 何かのようなもの あなた(またはあなたに代わって他の人)は、コードレビューのためにレビュー(スニペット、シングルコミット、または一連)を投稿できます。 他の人はそれについてコメントすることができます(SEの回答に似ています) バッジを与える/提案することができます(一部は良いもの、一部は「Comment Desert」などのように悪いもの) コード自体とコメントとバッジに賛成票または反対票を投じることができます(例:誰かがバッジを提案し、あなたが同意した/同意しなかった場合) このようなスキームの目的は コードレビューの使用を促進するために、ちょっとした楽しみを紹介します 品質の向上(このスキームでは、コードのレビュー対象者とレビュー担当者の両方が学習する可能性が高い) コードレビューが「自我戦争」を引き起こす可能性を減らす 個々のパフォーマンスの測定に役立つメトリックを提供します これは機能しますか?考え?

8
他の誰かがリファクタリングの問題を抱えていますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 かなりの量のコードを書いた後、可能な限り最善の方法でそれをしていないような不安を感じ、最終的にリファクタリングを続け、プロジェクトにあまりにも多くの時間を費やしているようです。時々やった。これは他の誰にも起こりますか、これにどのように対処しますか?

8
ソフトウェアの正式な方法を学んだ場合、それはどれほど有用ですか?
プログラミングのための正式な方法(FM)の使用に関するトレーニングを受けている場合: あなたはそれをどれほど便利に見つけましたか? FMトレーニングには何が含まれていましたか(コース、本など)。 どのFMツールを使用していますか? FMを使用しない場合と比べて、速度/品質の面でどのような利点がありますか? FMでどのようなソフトウェアを作成しますか? そして、FMを直接使用しない場合、少なくとも学ぶ価値はありましたか?? 私はこのコミュニティで見られるようなFMに関する多くの経験/意見を聞きたいです。私はそれについて読み始めており、もっと知りたいです。 バックグラウンド プログラミングとソフトウェア開発/エンジニアリングは、地球上の最新の人間のスキル/職業の一部です。そのため、当然のことながら、フィールドは未熟です。これは、通常遅れてエラーが発生しやすいコードとしてフィールドのメイン出力に表示されます 業界の未熟さは、平均的なコーダーとトップのコーダーの間の生産性の大きなマージン(少なくとも10:1)によっても示されます。そのような陰惨な事実は文献で十分にカバーされており、Steve McConnellのCode Completeなどの本で紹介されています。 エラーの根本的な原因(プログラミングの数学的厳密性の欠如)の1つに対処するために、ソフトウェア/ CSの主要人物(E.ダイクストラなど)によって正式な方法(FM)の使用が提案されています。たとえば、ダイクストラは、プログラムとその証明を一緒に開発する学生を提唱しました。 FMは、米国に比べてヨーロッパのCSカリキュラムではるかに普及しているようです。しかし、過去数年間で、新しい「軽量」FMアプローチと合金のようなツールが注目を集めています。それでも、FMは業界で一般的な使用法とはほど遠いので、ここでその理由についてのフィードバックを期待しています。 更新 現在(2010年10月14日)、以下の6つの回答のうち、「現実の世界」でのFMの使用について明確に主張している人はいません。誰かができるかどうか、私は本当に興味があります。あるいは、FMは、学界(FMは未来です!)と産業(FMはほとんど役に立たない)の違いを実際に示しています。

9
深いインデントを防ぐ方法は?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 コードの深いインデントを防ぐために、どのような手順と対策を講じることができますか?

6
コードの複製はCで必要な悪ですか?
私はCを初めて使用しますが、一般的なデータ構造とCの一般的な記述に関して、コードの重複が必要な悪なのかどうか疑問に思っています。 hash mapたとえば、一般的な実装を記述しようとすることもできますが、最終結果は常に乱雑になります。また、この特定のユースケースだけに特化した実装を記述し、コードを明確に保ち、​​読みやすくデバッグしやすくすることもできます。後者はもちろん、コードの重複につながります。 一般的な実装は標準ですか、それともユースケースごとに異なる実装を作成しますか?

3
コードメトリックとバグ密度を相関させる実験
誰かがコードメトリックス(SLOC、Cyclomatic Complexityなど)とオブジェクト指向アプリケーションのバグ密度を相関させる実験を行ったかどうか疑問に思っています。 私は相関関係を証明または反証するだけの実験を探しているのではなく、両方で実験を探しています。私はプロジェクトのバグ密度がいることを信じているよう特効薬を発見するつもりはないよ可能性がある特定のプロジェクトやチームのための1つまたは複数のメトリックに相関と相関がプロジェクト/チームの存続期間中に変更することができます。 私の目標は 興味深い指標をすべて2〜3か月間測定します(ソナーからはすでにかなりの数があります)。 新しいバグの数と相関する1つのメトリックを見つけます。 根本原因分析を行って、これがなぜ起こるのかを確認します(たとえば、特定の設計スキルが不足していますか?)。 いくつかの反復のスキルを向上させ、変化を測定します。 すすぎ、2から繰り返します。 これに関する経験はないが、このテーマに関する論文/ブログを見たことを覚えているなら、それを共有できれば幸いです。 これまでのところ、このテーマに関するいくつかの情報を含む次のリンクを見つけました バグは複雑なコードにありますか?-プレゼンテーションのスライドのみ。 変更点とバグ:開発アクティビティのマイニングと予測 -プレゼンテーションからスライドするだけです。要するに、依存関係が多いほど、バグが発生する可能性が高くなります(これは非常に一般的なルールだと思います)。 失敗は4文字の言葉です -バグとメトリックの相関関係に関するパラディ。

10
長期的にアウトソーシングコードはより高価ですか?コードの品質に悪影響を及ぼしますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 2年前に閉店。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私は、まともなソフトウェア製品の知的財産を所有し、年間のライセンス供与から素晴らしい収入を得ている会社を知っています。ただし、ディレクター(非技術的)は、利益率を大きく食い尽くして開発チームを維持するためのコストについて不満を述べ、特定のモジュールの開発を低料金で課金する他の国へのアウトソーシングを検討しています。 個人的には、これが長期的にはより費用対効果の高いソリューションになるとは思いません。これにより、問題が発生した場合に通信障害が発生する可能性があります。さらに、仕様を水密にする必要があり、いずれにしても時間がかかる可能性があります。私の意見では、チームで作業する場合、コミュニケーションが重要です。または、この作業を効果的に行う方法はありますか?

6
プロジェクトが特に複雑なのか、それとも取り上げるのが遅いのかを判断するにはどうすればよいですか?
私は主要なプロジェクトでほとんど進歩を遂げていません。ソースは巨大で、オブジェクトの多くのレイヤー、マカロニコード、多重継承のダブルダイヤモンドグラフ、元の作家が去ったときに中途半端な機能が凍結されており、その多くの部分がそのように設計された理由は誰にもわかりません。 有能なプログラマーなら、バグを修正し、中途半端なものを完成させ、新しい機能を追加するのに十分なほどうまくそれを理解するのに苦労すると思う。しかし、私は典型的なプログラマーよりも遅くなると思う。 ソースが異常に悪く、私ができることは誰でもできるかどうかを判断するにはどうすればよいのでしょうか?ソースはこのようなプロジェクトでは典型的であり、私はただの機知に欠けているか、未熟です?

5
正式なコードレビューを実施する際に役立つ考え方
当社のチームは最近、各チェックインに対してコードレビューの実施を開始しました。 チームのリーダーとして、私はあまりにも多くの提案を提供し、開発者をいらいらさせ、チームの出力を減らし、コードを手放すというバランスを見つけようとしています。 有用なアプローチを示唆する、よく知られた情報源からの証拠、研究、またはガイダンスはありますか?

6
コードカバレッジ分析のコードを除外する必要がありますか?
私はいくつかのアプリケーション、主にレガシーなものに取り組んでいます。現在、それらのコードカバレッジは非常に低く、通常は10〜50%です。 数週間以来、Cobertura(現在JaCoCoに移行している場合でも、コードカバレッジツール)のパッケージまたはクラスの除外について、バンガロールチームと頻繁に議論しています(開発の主な部分はインドのオフショアで行われます)。 彼らの視点は次のとおりです。アプリケーションの一部のレイヤーで単体テストを作成しないため(1)、これらのレイヤーはコードカバレッジ測定から単に除外する必要があります。言い換えれば、彼らはテストされているかテストされるべきコードにコードカバレッジ測定値を制限したいのです。 また、複雑なクラスの単体テストで作業する場合、その利点(純粋にコードカバレッジの観点から)は、大規模なアプリケーションでは見過ごされます。コードカバレッジの範囲を縮小すると、この種の作業がより明確になります... このアプローチの興味は、テスト可能であると考えるアプリケーションの部分の現在の状態を示すコードカバレッジ測定を持つことです。 しかし、私の見解では、私たちは何らかの形で数字を偽造しています。このソリューションは、労力をかけずに、より高いレベルのコードカバレッジに到達する簡単な方法です。気になるもう1つの点は、ある週から別の週へのカバレッジの増加を示した場合、この良いニュースが開発者の良い仕事によるものなのか、単に新しい除外によるものなのかをどのように見分けることができますか? さらに、コードカバレッジ測定で何が考慮されているかを正確に知ることはできません。たとえば、コード適用範囲が40%のコードアプリケーションが10,000行ある場合、コードベースの40%がテストされていると推定できます(2)。しかし、除外を設定するとどうなりますか?コードカバレッジが60%になった場合、正確に何を差し引くことができますか?「重要な」コードベースの60%がテストされていますか?どうやって 私が懸念している限りでは、「本当の」コードカバレッジ値を維持することを好みます。さらに、Sonarのおかげで、コードベースを簡単にナビゲートし、モジュール/パッケージ/クラスについて、独自のコードカバレッジを知ることができます。しかし、もちろん、グローバルなコードカバレッジはまだ低いでしょう。 その主題についてのあなたの意見は何ですか?あなたのプロジェクトはどうしますか? ありがとう。 (1)これらのレイヤーは、一般的にUI / Java Beanなどに関連しています。 (2)それは真実ではないことを知っています。実際、それは私のコードベースの40%

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.