coding-style - ソフトウェア会社は開発者にコーディングスタイルを課すべきだと思いますか?

Question

そうすべきではないと思うなら、その理由を説明してください。

はいの場合、ガイドラインはどの程度深いものであるべきだと思いますか? たとえば、コードのインデントを含める必要がありますか?

score 34 · Accepted Answer

チーム(会社ではなく) は、合理的に一貫したスタイルの一連のガイドラインに同意する必要があると思います。これにより、メンテナンスがより簡単になります。

どれぐらい深い？あなたが同意できる限り浅い。短く明確にすればするほど、チームメンバー全員が同意し、遵守する可能性が高くなります。

score 8 · Accepted Answer

誰もが標準的な方法でコードを読み書きできるようにする必要があります。これを実現するには、次の 2 つの方法があります。

1 人の開発者を数回複製し、全員が同じトレーニングを受けていることを確認します。願わくば、彼ら全員が同じコードベースを書けるようになるべきです。
必要なものについて、既存の開発者に明確な指示を与えます。インデント用のタブまたはスペース。ブレースが座る場所。コメントの仕方。バージョン管理コミットのガイドライン。

未定義のままにしておくほど、開発者の 1 人がスタイルで衝突する可能性が高くなります。

score 7 · Accepted Answer

ソフトウェア会社は開発者にコーディングスタイルを課すべきだと思いますか?

トップダウン方式ではありません。ソフトウェア会社の開発者は、共通のコーディングスタイルに同意する必要があります。

はいの場合、ガイドラインはどの程度深いものであるべきだと思いますか?

偏差を最小限に抑えようとして、よく知られた規則との違いのみを説明する必要があります。これは、Python や Java などの言語では簡単ですが、C/C++ ではやや曖昧で、Perl や Ruby ではほとんど不可能です。

たとえば、コードのインデントを含める必要がありますか?

はい、コードがはるかに読みやすくなります。スペースとタブ、および (スペースを選択した場合) スペース文字の数に関して、インデントの一貫性を保ちます。また、長い行の余白 (例: 76 文字または 120 文字) について合意します。

score 7 · Accepted Answer

会社は、何らかのスタイルに従うように強制する必要があります。それがどのようなスタイルであり、ガイドラインがどの程度深いものであるかは、社内の開発者コミュニティによってまとめて決定されるべきです。

中括弧、インデント、命名などに関するガイドラインを明確に定めます。読みやすさと保守性のためにコードを記述します。他の誰かがあなたのコードを読むと常に想定してください。コードを魔法のように自動的にフォーマットするツールがあり、すべての人にそのツールを使用するように義務付けることができます。

.Net を使用している場合は、stylecop、fxcop、および Resharper を参照してください。

score 5 · Accepted Answer

はい、しかし妥当な範囲内です。

最近のすべての IDE は 1 回のキーストロークでコードをきれいに印刷できるので、私の意見では、「インデント」ポイントはまったく関係ありません。

さらに重要なことは、ベストプラクティスを確立することです。たとえば、「out」または「ref」パラメーターをできるだけ少なく使用するなどです。この例では、2 つの利点があります。 of out parameters はコードの匂いであり、おそらくリファクタリングする必要があります)。

それを超えることは、私の正直な意見では、少し「肛門」であり、開発者にとって不必要に迷惑です.

ハミッシュ・スミスによる良い点:

スタイルは、ベストプラクティスとはかなり異なります。「コーディング標準」がこの 2 つを一緒にする傾向があるのは残念です。人々がスタイルの部分を最小限に抑え、ベストプラクティスに集中できれば、おそらくより多くの価値が追加されるでしょう。

score 4 · Accepted Answer

開発チームが、原則として従わなければならないスタイルガイドラインを持つべきだとは思いません。#include ステートメントでの <> と "" の使用などの例外がありますが、これらの例外は必要に応じて発生する必要があります。

スタイルガイドラインが必要な理由を説明するために人々が使用する最も一般的な理由は、共通のスタイルで記述されたコードは、個々のスタイルで記述されたコードを維持しやすいからです。同意しません。プロのプログラマーは、これを見ても行き詰まることはありません。

for( int n = 0; n < 42; ++42 ) {
 // blah
}

...これを見ることに慣れている場合:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

さらに、元のコードを書いたプログラマーのスタイルを認識するだけでそのプログラマーを特定できれば、実際にはコードの保守が容易になる場合もあります。彼らが予期しないことをした非常に技術的な理由を理解するために 1 日の大部分を費やすのではなく、10 分でそのような複雑な方法でギズモを実装した理由を彼らに尋ねてください。確かに、プログラマーは理由を説明するためにコードにコメントするべきでしたが、現実の世界では、プログラマーはしばしばそうしません。

最後に、ジョーが 10 分バックスペーシングして中かっこを移動し、ビルがコードを見るのに 3 秒も費やすことができない場合、ビルに彼にとって自然ではないことをさせるために、本当に時間を節約できたでしょうか?

score 3 · Accepted Answer

一貫したコードベースを持つことが重要だと思います。コードの保守性が向上します。誰もが同じ種類のコードを期待していれば、簡単に読んで理解できます。

その上、今日の IDE とその自動フォーマット機能を考えると、それほど面倒ではありません。

PS: 次の行に中かっこを置くという厄介な癖があります :)。他の誰もそれを好きではないようです

score 2 · Accepted Answer

最善の解決策は、IDEがそのようなフォーマットをメタデータと見なすことです。たとえば、中括弧の開始位置（現在の行または次の行）、演算子の周りのインデントおよび空白は、ソースファイルを変更せずに構成可能である必要があります。

score 2 · Accepted Answer

プログラマーは他のプログラマーのスタイルに適応できるべきだと思います。新しいプログラマーが適応できない場合、それは通常、新しいプログラマーが頑固すぎて会社のスタイルを使用できないことを意味します。私たち全員が自分のことをできるといいですね。ただし、何らかのガイドラインに沿ってコーディングすれば、デバッグとメンテナンスが容易になります。これは、標準がよく考えられていて、制限が厳しすぎない場合にのみ当てはまります。

すべてに同意するわけではありませんが、この本には標準化の優れた出発点が含まれています。

score 1 · Accepted Answer

他の人が言ったように、私はそれがエンジニアリングまたはチームによるものである必要があると思います-会社（すなわちビジネスユニット）はその種の決定に関与するべきではありません。

しかし、もう1つ追加したいのは、実装されるルールは、人ではなくツールによって適用される必要があるということです。最悪のシナリオであるIMOは、熱心すぎる文法スノッブです（はい、私たちは存在します。私たちは自分の匂いを嗅ぐことができるので知っています）は、実際には誰も読んだり従ったりしない一連のコーディングガイドラインの概要を説明するドキュメントを作成します。それらは時間の経過とともに時代遅れになり、新しい人々がチームに追加され、古い人々が去るにつれて、彼らは単に古くなります。

次に、いくつかの競合が発生し、誰かがコーディングスタイルについて他の誰かと対峙しなければならないという不快な立場に置かれます。この種の対決は、人ではなくツールによって行われる必要があります。要するに、私の意見では、この強制の方法は、無視するのが非常に簡単であり、単にプログラマーに愚かなことについて議論するように頼むので、最も望ましくありません。

より良いオプション（ここでもIMO）は、ビルド環境がこれをサポートしている限り、コンパイル時に（または同様の何かで）警告をスローすることです。VS.NETでこれを構成するのは難しいことではありませんが、同様の機能を備えた他の開発環境を私は知りません。

score 1 · Accepted Answer

スタイルガイドラインは、それがデザインであれ開発であれ、非常に重要です。スタイルガイドラインは、協力して作業する人々のコミュニケーションとパフォーマンスをスピードアップするためです (または、古いプロジェクトの断片を拾い上げるときのように、1 人で順番に作業する場合でも)。会社内に慣例のシステムがないということは、人々にできる限り非生産的になることを求めているだけです。ほとんどのプロジェクトは共同作業を必要としますが、共同作業を必要としないプロジェクトでさえ、プログラミングの技術を駆使して最新の状態に保ちたいという私たちの自然な欲求に対して脆弱になる可能性があります。学びたいという私たちの欲求は、私たちの一貫性を妨げます。それ自体は良いことですが、新入社員が飛び込んでいるシステムを学ぼうとして気が狂ってしまう可能性があります。

悪ではなく善を目的とした他のシステムと同様に、ガイドの真の力はその人々の手にあります。開発者自身が重要で有用な部分を判断し、できればそれらを使用します。

法律のように。または英語。

スタイルガイドは、彼らが望んでいるほど深くする必要があります。ブレーンストーミングセッションで話題になった場合は、それを含める必要があります。スタイルガイドはガイドにすぎないため、結局のところ、スタイルガイドを「課す」方法がないため、質問の言い方は奇妙です。

RTFM、それから良いものを集めて、それを続けてください.

score 1 · Accepted Answer

私の意見では、標準とスタイルガイドには非常に必要だと思います。コードベースが大きくなると、一貫性を持たせたいと思うからです。

補足として、それが私が Python を愛する理由です。アプリケーションの構築方法などについて、すでにかなり多くのルールが課せられているためです。それをPerl、Ruby、または極端な自由があるものと比較してください（この場合はそれほど良くありません）。

score 1 · Accepted Answer

アプリケーションの開発方法とコードの外観を標準で定義するのには、十分な理由があります。たとえば、誰もが同じ標準を使用している場合、自動スタイルチェッカーをプロジェクト CI の一部として使用できます。同じ標準を使用すると、コードの可読性が向上し、同じコードをさまざまな方法でリファクタリングすることに関するチームメンバー間の緊張を緩和するのに役立ちます。したがって：

特定のチームによって開発されたすべてのコードは、正確に同じ標準に従う必要があります。
特定のプロジェクト用に開発されたすべてのコードは、正確に同じ標準に従う必要があります。
同じ会社に所属するチームは、同じ基準を使用することが望ましい。

アウトソーシング会社では、顧客が独自の標準を強制したい場合、顧客のために働くチームに例外を設けることができます。この場合、チームは顧客の標準を採用しますが、これは会社が使用するものと互換性がない可能性があります。

score 0 · Accepted Answer

Ilyaの答えは、読みやすさの重要性と、強制メカニズムとしての継続的インテグレーションの使用が組み込まれているため、気に入っています。HibriはFxCopについて言及しました。ビルドが成功するか失敗するかを判断するための基準の1つとして、ビルドプロセスでの使用は、単に標準を文書化するよりも柔軟で効果的だと思います。

score 0 · Accepted Answer

私は、コーディング標準を適用する必要があり、ほとんどの場合、チームレベルで行う必要があることに完全に同意します。ただし、いくつかの例外があります。

チームが他のチームが使用するコードを作成している場合（ここでは、他のチームがソースをライブラリとして使用するだけでなく、ソースを確認する必要があることを意味します）、すべてのチームに共通の標準を作成することには利点があります。それを使用します。同様に、会社のポリシーがプログラマーをあるチームから別のチームに頻繁に移動することである場合、またはあるチームが別のチームのコードを頻繁に再利用したいという立場にある場合は、会社全体に標準を課すのがおそらく最善です。

score 0 · Accepted Answer

私は一貫性が鍵であることに同意します。一部の開発者はIDEの使用を好まない可能性があり、何千ものソースファイルのコードベースをトロールしている場合、それをきれいにするのは簡単ではないため、IDEのきれいな印刷に頼ることはできません。作業を開始するときにすべてのファイルを印刷し、後でロールバックを実行して、VCSがすべての変更をコミットバックしようとしないようにします（すべての人に負担をかける不必要な更新でリポジトリを詰まらせます）。

少なくとも以下を標準化することをお勧めします（重要度の高いものから順に）。

ホワイトスペース（共有ツールの自動プリティプリントに準拠したスタイルを選択するのが最も簡単です）
命名（ファイルとフォルダー、クラス、関数、変数、...）
コメント（自動ドキュメント生成を可能にする形式を使用）

score 0 · Accepted Answer

共通のコーディングスタイルは一貫性を促進し、さまざまな人々が自分の部分だけでなく、コードベース全体を簡単に理解し、維持し、拡張できるようにします。また、新しい人がコードをより早く習得しやすくなります。したがって、どのチームも、コードの記述方法に関するガイドラインを持つ必要があります。

重要なガイドラインは次のとおりです (順不同)。

空白とインデント
標準コメント - ファイル、クラス、またはメソッドのヘッダー
命名規則 - クラス、インターフェース、変数、名前空間、ファイル
コード注釈
プロジェクトの編成 - フォルダ構造、バイナリ
標準ライブラリ - 使用するテンプレート、ジェネリック、コンテナなど
エラー処理 - 例外、hresults、エラーコード
スレッド化と同期

また、どんなに頭が良くても、チームのスタイルに適応できない、または適応しようとしないプログラマーには用心してください。チームルールの 1 つに従ってプレイしない場合、他のチームルールでもプレイしない可能性があります。

score 0 · Accepted Answer

最新の IDE では、書式設定テンプレートを定義できます。企業標準がある場合は、関心のあるすべての書式設定値を定義する構成ファイルを作成し、コードをチェックインする前に全員がフォーマッターを実行するようにします。さらに厳密にしたい場合は、バージョン管理システムにコミットフックを追加して、コードが受け入れられる前にインデントすることができます。

score 0 · Accepted Answer

2 種類の規約があります。

タイプ A の慣例: 「これらを実行してください。そのほうがよい」

タイプB：「道路の右側を運転してください」ですが、反対側を運転しても問題ありません。

個別のチームというものはありません。優れた企業のすべてのコードは何らかの方法で接続されており、スタイルは一貫している必要があります。20 の異なるスタイルに慣れるよりも、1 つの新しいスタイルに慣れる方が簡単です。

また、新しい開発者は、既存のコードベースの慣行を尊重し、それに従うことができなければなりません。

score 0 · Accepted Answer

はい、企業はそうすべきだと思います。開発者はコーディングスタイルに慣れる必要があるかもしれませんが、私の意見では、優れたプログラマーはどのようなコーディングスタイルでも作業できるはずです。Midhat が言ったように: 一貫したコードベースを持つことが重要です。

これはオープンソースプロジェクトにとっても重要だと思います。コードの書き方を教えてくれるスーパーバイザーはいませんが、多くの言語には、コードの命名方法と編成方法に関する仕様があります。これは、オープンソースコンポーネントをプロジェクトに統合する際に非常に役立ちます。

score 0 · Accepted Answer

確かに、ガイドラインは良いものであり、使い方の悪いハンガリー語表記 (ha!) でない限り、おそらく一貫性が向上し、他の人のコードが読みやすくなるでしょう。ただし、ガイドラインは単なるガイドラインであるべきであり、プログラマーに強制される厳密な規則ではありません。中かっこをどこに置くか、temp のような名前を使用しないように指示することはできますが、できないことは、配列の大かっこ内のインデックス値の周りにスペースを強制することです (彼らは一度試しました...)

score 0 · Accepted Answer

はい。

コーディング標準は、特定の組織内のコードが最小の驚きの原則に従うことを保証する一般的な方法です。変数の命名からインデント、中括弧の使用まで、標準の一貫性です。

独自のスタイルと独自の基準を持つコーダーは、特に大規模なプロジェクトでは、一貫性がなく、混乱し、読むのにイライラするコードベースしか生成しません。

score 0 · Accepted Answer

私の意見：

誰もがコードを読んで維持するのに役立つので、いくつかの基本的なルールは良いです
ルールが多すぎると、コードをより明確な方法でレイアウトする開発者の革新が妨げられるため、良くありません。
個々のスタイルは、コードファイルの履歴を判断するのに役立ちます。差分/非難ツールを使用できますが、ヒントは引き続き役立ちます

score 0 · Accepted Answer

エバー言語には、コミュニティで使用される一般的な基準があります。言語に慣れている他の人がコードを保守できるように、可能な限りそれらに従う必要がありますが、独裁的である必要はありません。

企業のコーディング標準は通常あまりにも厳格であり、その言語を使用している一般的なコミュニティに対応できないため、公式標準の作成は間違っています。

チームメンバーがコーディングスタイルに問題を抱えている場合は、グループがコードレビューでそれは良い考えではないことを穏やかに示唆することは素晴らしいことです。

score 0 · Accepted Answer

コーディング基準: はい。このスレッドで既に説明されている理由によります。

スタイリング基準：NO. あなたの読みやすさは私の当惑するがらくたであり、その逆も同様です。適切なコメントとコードファクタリングには、はるかに大きなメリットがあります。また、gnuインデント。

score 0 · Accepted Answer

これらは、私が以前働いていた会社のコーディング標準です。それらは明確に定義されており、慣れるまでに少し時間がかかりましたが、コードは私たち全員が読みやすく、全体を通して統一されていました。

企業内でコーディング標準は重要だと思います。何も設定されていないと、開発者間で衝突が発生し、読みやすさの問題が発生します。

コードを一貫して統一することで、より良いコードをエンドユーザーに提供できます (つまり、1 人の人物によって書かれたかのように見えます。エンドユーザーの観点からは、そうあるべきです。その人物は「会社」であり、チーム内での読みやすさにも役立ちます...

score 0 · Accepted Answer

はい。共通の命名基準、およびクラスとコードビハインドファイルの共通のレイアウトを使用するという点では、そうです。他のすべては開いています。

score 0 · Accepted Answer

どの企業もそうすべきです。一貫したコーディングスタイルにより、チーム全体でコードベースの可読性と保守性が向上します。

私が働いているショップには統一されたコーディング標準がなく、私たち (チームとして) はそのことに非常に苦しんでいると言えます。個人からの意志がない場合 (私の同僚の場合のように)、チームリーダーはテーブルにこぶしをぶつけて、何らかの標準化されたコーディングガイドラインを課す必要があります。

coding-style - ソフトウェア会社は開発者にコーディング スタイルを課すべきだと思いますか?

28 に答える 28

Related

Reference

coding-style - ソフトウェア会社は開発者にコーディングスタイルを課すべきだと思いますか?