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

https://stackoverflow.com/questions/145508

02-07-2019
|

質問

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

「はい」の場合、ガイドラインはどの程度深くする必要がありますか？たとえば、コードのインデントを含める必要がありますか？

解決

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

深さは？あなたが同意できる限り浅い。短くて明確であればあるほど、すべてのチームメンバーがそれに同意し、それを順守する可能性が高くなります。

他のヒント

すべての人が標準的な方法でコードを読み書きしたい場合。これを実現する方法は2つあります：

1人の開発者を数回クローンし、全員が同じトレーニングを受けることを確認します。全員が同じコードベースを記述できることを願っています。
既存の開発者に、必要なものを明示的に指示します。インデント用のタブまたはスペース。ブレースが置かれる場所。コメントする方法。バージョン管理コミットのガイドライン。

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

会社は、何らかのスタイルに従う必要があることを課すべきです。そのスタイルとガイドラインの深さは、社内の開発者コミュニティがまとめて決定する必要があります。

ブレース、インデント、ネーミングなどに関するガイドラインを間違いなく書きます。読みやすく保守しやすいコードを作成します。他の誰かがあなたのコードを読むことを常に想定してください。コードを魔法のように自動的にフォーマットするツールがあり、誰でもそのツールを使用することを義務付けることができます。

.Netを使用している場合は、stylecop、fxcop、Resharperをご覧ください

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

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

「はい」の場合、ガイドラインの深さはどの程度ですか？

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

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

はい、コードがずっと読みやすくなります。スペースとタブ、および（スペースを選択した場合）スペース文字の数に関してインデントの一貫性を保ちます。また、長い行のマージン（76文字または120文字など）に同意します。

はい、ただし理にかなっています。

最新のIDEはすべて、ワンキーストロークコードできれいに印刷できるため、<！> quot; indentation <！> quot;私の意見では、この点はまったく無関係です。

より重要なことは、ベストプラクティスを確立することです。たとえば、「<！> quot; out <！> quot;または<！> quot; ref <！> quot;可能な限りのパラメーター...

それを超えると、正直なところ、少し<！> quot; anal <！> quot;開発者にとっては不必要に迷惑です。

ハミッシュ・スミスの良い点：

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

私は、開発チームが一般的なルールとして従わなければならないスタイルのガイドラインを持つべきだとは思いません。例外があります。たとえば、 <！> lt; <！> gt;の使用対<！> quot; <！> quot; #includeステートメントでは、これらの例外は必要に応じて発生する必要があります。

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

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

...これを見ることに慣れているとき：

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

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

最後に、Joeがバックスペースを<！> ampするのに10分かかる場合。ビルがコードを見るのに3秒もかからないように中括弧を移動します。ビルに彼にとって自然ではない何かをさせる時間を本当に節約しましたか？

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

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

PS：次の行にブレースを置くという面倒な癖があります:)。他の誰もそれを好きではないようです

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

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

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

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

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

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

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

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

他の人が言ったように、それはエンジニアリングまたはチームによるものである必要があると思います-会社（つまり、事業単位）はそのような決定に関与すべきではありません。

しかし、私が追加したいもう1つのことは、実装されるルールはツールによって強制されるべきであり、人々によって強制されるべきではないということです。最悪のシナリオであるIMOは、熱心な文法スヌーブです（はい、私たちは自分自身の匂いがするので、私は知っています）、実際に読んだり従うことのないコーディングガイドラインのセットを概説するドキュメントを書いています。それらは時間とともに陳腐化し、新しい人々がチームに追加され、古い人々が去ると、彼らは単に古くなります。

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

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

スタイルガイドラインは、共同作業（または単独で、古いプロジェクトの断片を拾うときのように順番に作業する人）のコミュニケーションとパフォーマンスを高速化するため、デザインまたは開発用であっても非常に重要です。企業内に慣習制度がないは、できる限り非生産的であることを人々に求めているだけです。ほとんどのプロジェクトはコラボレーションを必要としますが、そうでないプロジェクトでさえ、プログラミングを実行して最新の状態を維持したいという私たちの自然な欲求に対して脆弱です。学習したいという欲求が一貫性の妨げになります-それ自体は良いことですが、飛び込んでいるシステムを学ぼうとしている新入社員を夢中にさせることができます。

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

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

スタイルガイドは、必要なだけ深くする必要があります。ブレインストーミングセッションで登場する場合は、含める必要があります。 1日の終わりには<！> quot; impose <！> quot; GUIDEにすぎないため、スタイルガイド。

RTFM、それから良いものを収集し、それを使います。

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

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

確かに、ガイドラインは良いものです。そして、ハンガリー語の表記法（ha！）を不適切に使用しない限り、おそらく一貫性が向上し、他の人のコードを読みやすくなります。ただし、ガイドラインは単なるガイドラインであり、プログラマーに適用される厳密な規則ではありません。かっこを置く場所やtempなどの名前を使用しない場所を教えてくれますが、できないのは、配列ブラケット内のインデックス値の周りにスペースを入れることです（一度試してみました...）

はい。

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

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

これらは、私が働いていた会社のコーディング標準です。それらはきちんと定義されており、慣れるまで少し時間がかかりましたが、コードは私たち全員が読み取り可能であり、ずっと統一されていました。

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

コード全体を統一することで、エンドユーザーに優れたコードを提供します（そのため、1人のユーザーが作成したように見えます-エンドユーザーの観点からすると、そのユーザーは<！> quot;会社<！> quot;また、チーム内の読みやすさにも役立ちます...

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

重要なガイドラインは次のとおりです（順不同）：

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

また、どんなに明るくても、チームのスタイルに適応できない、または適応しないプログラマーには注意してください。チームルールの1つでプレイしない場合、おそらく他のチームルールでもプレイしません。

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

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

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

私の意見：

いくつかの基本的なルールは、誰もがコードを読んで保守するのに役立つため、優れています
コードをより明確にレイアウトする方法で開発者が革新するのを止めるため、ルールが多すぎると悪いです
個々のスタイルは、コードファイルの履歴を判断するのに役立ちます。 Diff / Blameツールを使用できますが、ヒントはまだ有用です

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

はい、クラスとコードビハインドファイルの共通レイアウトだけでなく、共通の命名標準を使用するという点でも。他のすべては開いています。

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

私が働いているお店には統一されたコーディング標準がありません。私たちは（チームとして）それに非常に苦しんでいると言えます。個人からの意思がない場合（同僚の場合など）、チームリーダーは拳をテーブルに打ち付け、何らかの形の標準化されたコーディングガイドラインを課す必要があります。

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

会社のコーディング標準は通常非常に厳格であり、言語を使用して一般のコミュニティとやり取りすることができないため、公式標準の作成は間違っています。

実際にコーディングスタイルでチームメンバーに問題がある場合、グループがコードレビューで優しく提案するのは良いことではありません。

コーディング標準：はい。このスレッドで既に説明した理由のため。

スタイリング基準：いいえ。あなたの可読性は、当惑させるジャンクです。優れたコメントとコードファクタリングには、はるかに大きな利点があります。また、gnuインデント。

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

コーディング標準が適用されるべきであり、ほとんど常にチームレベルであることに同意します。ただし、いくつかの例外があります。

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

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

タイプAの規則：<！> quot;これらを実行してください。<！> quot;

およびタイプB：<！> quot;道路の右側を運転してください<！> quot;。反対側を運転しても大丈夫です。 p>

別のチームのようなものはありません。良い会社のすべてのコードは何らかの形でつながっており、スタイルは一貫している必要があります。 20種類のスタイルよりも1つの新しいスタイルに慣れる方が簡単です。

また、新しい開発者は既存のコードベースの慣行を尊重し、それに従うことができるはずです。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow