c++ - コードを改善するためのガイドライン

Question

コードの全体的な品質を向上させるために、どのガイドラインに従っていますか? 多くの人は、C++ コードの書き方について、(おそらく) 間違いを犯しにくくするルールを持っています。私は、すべてのステートメントの後に中括弧ブロック ( ) が続くと主張する人を見てきました。if{...}

他の人がどのようなガイドラインに従っているのか、その背後にある理由に興味があります。あなたがくだらないと思うが、一般的に保持されているガイドラインにも興味があります。誰かがいくつか提案できますか？

ボールを転がすために、最初にいくつか言及します。

ifすべての/ステートメントの後には常に中かっこを使用しますelse(上記を参照)。この背後にある理論的根拠は、単一のステートメントが実際に 1 つのステートメントなのか、それとも複数のステートメントに展開されるプリプロセッサマクロなのかを判断するのは必ずしも容易ではないため、このコードは壊れてしまうからです。

    // ファイルの先頭:
    #定義文 doSomething(); doSomethingElse

    // 実装時:
    もし (何らかの条件)
        doSomething();

ただし、中括弧を使用すると、期待どおりに機能します。

条件付きコンパイルのみにプリプロセッサマクロを使用します。プリプロセッサマクロは、C++ スコープ規則を許可しないため、あらゆる種類の地獄を引き起こす可能性があります。ヘッダーファイルに共通の名前を持つプリプロセッサマクロが原因で、何度も行き詰まりました。注意しないと、あらゆる種類の混乱を引き起こす可能性があります。

さあ、あなたに。

score 9 · Accepted Answer

私の個人的なお気に入りのいくつか：

const correctであるコードを書くように努めてください。簡単に修正できるが、時には厄介なバグを取り除くのを助けるために、コンパイラに参加してもらいます。あなたのコードは、それを書いた時点であなたが何を考えていたかについてのストーリーも伝えます。

メモリ管理ビジネスから抜け出します。std::auto_ptr、std::tr1::shared_ptr(またはboost::shared_ptr)、およびのスマートポインターの使用方法を学びますboost::scoped_ptr。それらの違いと、どちらを使用するかを学びます。

おそらく標準テンプレートライブラリを使用することになるでしょう。Josuttisの本を読んでください。STL を知っていると思って、コンテナに関する最初の数章を読んだだけでやめないでください。アルゴリズムや関数オブジェクトなど、優れたものを突き詰めてください。

score 9 · Accepted Answer

9

不要なコードを削除します。

それだけです。

于 2008-09-13T18:00:22.727 に答える

score 7 · Accepted Answer

共通のコーディングスタイルとガイドラインを使用して実施します。理論的根拠:チームまたは会社のすべての開発者は、さまざまなブレーススタイルまたは同様のものによって発生する可能性のある注意をそらすことなく、コードを読むことができます。
定期的にソースベース全体の完全な再構築を行い (つまり、毎日のビルドまたは各チェックイン後にビルドを行います)、エラーがあれば報告してください。理論的根拠:ほとんどの場合、ソースは使用可能な状態にあり、問題解決が安価な「実装」後すぐに問題が検出されます。

score 7 · Accepted Answer

コンパイラで耐えられるすべての警告をオンにし (gcc:-Wallは良いスタートですが、すべてが含まれているわけではないのでドキュメントを確認してください)、それらをエラーにして修正する必要があります (gcc: -Werror)。

score 5 · Accepted Answer

これらの回答の1つで言及されているGoogleのスタイルガイドは、かなりしっかりしています。意味のないものもあるが、悪いよりは良い。

Sutter と Alexandrescu は、このテーマについてC++ Coding Standardsというまともな本を書きました。

以下は、lil' ole me からの一般的なヒントです。

インデントと括弧のスタイルはどちらも間違っています。他のみんなもそうです。したがって、これについてはプロジェクトの基準に従ってください。プライドを捨てて、コードベースの残りの部分とすべてが可能な限り一致するようにエディターをセットアップしてください。一貫性のないインデントされたコードを読まなければならないのは本当に面倒です。とはいえ、ブラケットとインデントは「コードの改善」とは何の関係もありません。それは、他の人と協力する能力を向上させることです。
よくコメントします。これは非常に主観的なものですが、一般的には、コードが何をするのかを説明するよりも、コードがなぜそのように機能するのかについてコメントを書くことは常に良いことです。もちろん、複雑なコードの場合、アルゴリズムやコードに精通していない可能性のあるプログラマーにとっても、それが何をしているのかを理解するのに役立ちます。採用されているアルゴリズムの説明へのリンクは大歓迎です。
ロジックをできるだけ単純な方法で表現します。皮肉なことに、「比較の左側に定数を置く」などの提案は、ここで間違っていると思います。それらは非常に人気がありますが、英語を話す人にとっては、プログラムの論理的な流れを読んでいる人にとってしばしば中断します. あなた自身 (またはあなたのコンパイラ) が等値比較を正しく書くことを信頼できない場合は、必ずこのようなトリックを使用してください。しかし、そうすると明快さが犠牲になります。また、このカテゴリに分類されるのは、「私のロジックには 3 レベルのインデントがありますか?もっと簡単にできますか?」などです。同様のコードを関数にまとめます。たぶん、機能を分割することさえあります。基礎となるロジックをエレガントに表現するコードを書くには経験が必要ですが、それに取り組む価値はあります。

それらはかなり一般的でした。具体的なヒントについては、Sutter と Alexandrescu ほど優れた仕事はありません。

score 4 · Accepted Answer

if ステートメントでは、左側に定数を置きます。

if( 12 == var )

いいえ

if( var == 12 )

「=」を入力し忘れると代入になるからです。最上位のバージョンでは、コンパイラはこれが不可能であると言いますが、後者では実行され、if は常に true です。

if が同じ行にないときはいつでも中かっこを使用します。

if( a == b ) something();
if( b == d )
{
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}

開き中括弧と閉じ中括弧は、常に独自の行を取得します。しかし、それはもちろん個人的な慣習です。

score 4 · Accepted Answer

コードが何をしているのかを説明する必要がある場合にのみコメントしてください。コードを読んでも同じことがわかりません。

もう使用しないコードはコメントアウトしないでください。古いコードを回復したい場合は、ソース管理システムを使用してください。コードをコメントアウトすると、見た目が乱雑になり、実際に重要なコメントがコメント化されたコードの背景の混乱に消えてしまいます。

score 3 · Accepted Answer

Google が内部的に使用している優れたC++ スタイルガイドもあり、ここで言及されているほとんどのルールが含まれています。

score 3 · Accepted Answer

一貫した書式を使用します。
レガシコードで作業する場合は、既存のフォーマットスタイルを使用します。ブレーススタイル。
Scott Meyer の著書『Effective C++』を入手する
Steve MConnell の著書 Code Complete を入手してください。

score 2 · Accepted Answer

たくさんのコメントを書き始めますが、これを機会としてコードをリファクタリングし、自明になるようにしてください。

すなわち:

for(int i=0; i<=arr.length; i++) {
  arr[i].conf() //confirm that every username doesn't contain invalid characters
}

もっと似ているはずだった

for(int i=0; i<=activeusers.length; i++) {
  activeusers[i].UsernameStripInvalidChars()
}

score 1 · Accepted Answer

また、いくつかの優れたテクニックについては、Googleのブログ「トイレでのテスト」をフォローすることをお勧めします。

score 1 · Accepted Answer

私はC++プロジェクトでPC-Lintを使用しており、特にMISRAガイドラインやScottMeyersの「EffectiveC++」や「MoreEffectiveC++」などの既存の出版物を参照する方法が好きです。静的分析ツールがチェックするルールごとに非常に詳細な理由を書くことを計画している場合でも、ユーザーが信頼する確立された出版物を指すことをお勧めします。

score 1 · Accepted Answer

これが私がC++の第一人者から与えられた最も重要なアドバイスであり、それは私のコードのバグを見つけるためにいくつかの重大な機会に私を助けました：

メソッドがオブジェクトを変更することになっていない場合は、constメソッドを使用します。
オブジェクトがオブジェクトを変更することになっていない場合は、パラメーターでconst参照とポインターを使用します。

これらの2つのルールを使用すると、コンパイラはコードのどこにロジックの欠陥があるかを無料で教えてくれます。

score 1 · Accepted Answer

1

半年後に見てみよう

于 2008-10-08T03:31:19.350 に答える

score 1 · Accepted Answer

可能であれば、ポストインクリメントの代わりにプリインクリメントを使用してください。

score 1 · Accepted Answer

同様に、ここでいくつかの有用な提案を見つけることができます: How do you make wrong code looking wrong? セマンティックエラーを回避するためにどのパターンを使用しますか?

score 1 · Accepted Answer

コーディング規則を設定し、関係者全員が規則に従うようにします (適切にインデントされていないため、次のステートメント/式がどこにあるかを把握する必要があるコードを読みたくないでしょう)。
常にコードをリファクタリングする (Martin Fowler 著の Refactoring のコピーを入手してください。長所と短所は本で詳しく説明されています)
疎結合コードを書く (自明なコードを書くことでコメントを書くことは避けてください。疎結合コードは、管理/変更への適応が容易になる傾向があります)
可能であれば、コードの単体テストを行ってください (または、マッチョな場合は TDD を使用してください)。
早期リリース、頻繁にリリース
時期尚早の最適化を避ける (プロファイリングは最適化に役立ちます)

score 1 · Accepted Answer

インデントにはタブを使用しますが、データをスペースで揃えます。これは、人々がタブのサイズを変更することでインデントの量を決定できることを意味しますが、物事が整列したままであることも意味します (たとえば、値を構造体)
可能であれば、常にマクロの代わりに定数またはインライン関数を使用する
ヘッダーファイルで 'using' を使用しないでください。ヘッダーをインクルードする人が (たとえば) グローバル名前空間にすべての std を必要としない場合でも、そのヘッダーを含むすべてが影響を受けるためです。

何かが約 80 カラムより長い場合は、複数の行に分割します。

if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
   BigVaribleIsValid(SomeVeryLongVaribleName))
{
    DoSomething();
}

演算子をオーバーロードして、ユーザーが期待することを実行させるだけです。たとえば、2dVector の + 演算子と - 演算子をオーバーロードしても問題ありません。
次のブロックが何をしているのかを説明するだけの場合でも、必ずコードにコメントを付けてください (例: 「このレベルに不要なすべてのテクスチャを削除する」)。おそらくあなたが去った後、誰かがそれで作業する必要があるかもしれませんが、何をしているのかを示すコメントのない数千行のコードを見つけたくないでしょう。

score 0 · Accepted Answer

0

適切にインデントしていることを確認してください

于 2008-09-13T16:50:23.957 に答える

score 0 · Accepted Answer

スマートポインターには、所有権を非常に明確に示す優れた方法があります。クラスまたは関数の場合:

生のポインターを取得した場合、何も所有していません。発信者の好意により、ポインティを使用することが許可されています。発信者は、ポインティがあなたよりも長く生き続けることを保証します。
weak_ptrを取得した場合、あなたはポインティを所有していません。その上、ポインティはいつでも消える可能性があります。
shared_ptrを取得した場合は、他のオブジェクトと一緒にオブジェクトを所有しているため、心配する必要はありません。ストレスは減りますが、コントロールも減ります。
auto_ptrを取得した場合、あなたはオブジェクトの唯一の所有者です。それはあなたのものです、あなたは王です。あなたには、そのオブジェクトを破壊するか、他の誰かに渡す (それによって所有権を失う) 力があります。

auto_ptr の場合は特に強いと思います。ある設計で auto_ptr を見れば、そのオブジェクトがシステムのある部分から別の部分に「さまよっている」ことがすぐにわかります。

これは、少なくとも私がペットプロジェクトで使用するロジックです。このトピックにいくつのバリエーションがあるかはわかりませんが、これまでのところ、このルールセットはうまく機能しています。

score 0 · Accepted Answer

うーん、もう少し具体的に書くべきだったかもしれません。

私は自分自身へのアドバイスを求めているわけではありません - 私は静的コード分析ツールを書いています (現在の商用製品は私が望むものには十分ではありません)。コードのエラー。

const の正確性やスマートポインターの使用などについて何人かが言及しています。インデントとコメントのチェックは、（とにかくプログラミングの観点から）行うのが少し難しいです。

c++ - コードを改善するためのガイドライン

21 に答える 21

Related

Reference