web-dev-qa-db-ja.com

ブロックするコメントに#if 0を使用する理由

コードをリバースエンジニアリングしているので、そのスタイルにはちょっとがっかりしますが、これらのことを行う正当な理由がないことを確認したかったのです。

それは私だけですか、これは恐ろしいコーディングスタイルですか

if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

そして、なぜコンパイルを意図していないコードをラップして

#if 0
....
#endif

コメントの代わりに？

編集：したがって、以下で説明されているように、これはflummox/* * /の可能性によるものです。

しかし、私はまだ理解していません。「//」を使用してコメントアウトをブロックするために、プログラミング環境ツールまたはお気に入りのテキストエディターのマクロを使用しないのはなぜですか。

これは視覚的にスキップする方がはるかに簡単でわかりやすいでしょうか？

私は[〜＃〜] c [〜＃〜]の経験がないだけで、なぜこれらのことが良いアイデアであるのかわからないのですか？それとも言い訳がなく、このコードはどれほど醜いですか？

ccompilationc-preprocessor
29
Jason R. Mick

削除されたブロックにブロックコメントが含まれている場合、#if 0はかなり頻繁に使用されます

それは良い習慣だとは言いませんが、かなり頻繁に見ます。

単一行のフロー制御+ステートメントは理解するのに十分簡単ですが、私は個人的には避けています（そして、私が禁止していたコーディングガイドラインのほとんどは禁止しています）。

ちなみに、タイトルを編集して、「ブロックコメントの代わりに#if 0を使用する理由」を少しわかりやすくしたいと思います

次のものがあれば

#if 0
        silly();
        if(foo)
           bar();
        /* baz is a flumuxiation */
        baz = fib+3;
#endif

#if 0/#endifを単純に/* */に置き換えると、コメントがフラミングの直後に終了し、その場所で*/を押すと構文エラーが発生します。上記の#endifの.

編集：1つの最後の注意、多くの場合、#if 0構文は、特に複数のバージョン、依存関係、またはハードウェアプラットフォームをサポートする必要がある場合、開発中に使用されるだけです。コードが次のように変更されるのは珍しいことではありません

#ifdef _COMPILED_WITHOUT_FEATURE_BAZ_
    much_code();
#endif

一元化されたヘッダーで、何百ものこれらの#define定数を定義します（または定義しません）。これは世界で最もきれいなことではありませんが、適切なサイズのプロジェクトで作業するたびに、ランタイムスイッチ、コンパイル時定数（this）、コンパイル時コンパイルの決定（異なる。 cppはバージョンによって異なります）、および時折テンプレートソリューション。それはすべて詳細に依存します。

あなたが開発者である間、最初から物事を機能させるだけですが、古いコードにまだ価値があるかどうかわからない場合は、#if 0が一般的です。

36
jkerian

コメントはコメントです。それらはコードを記述します。

コンパイルから除外されているコードは、コメントではなくコードです。今のところ、コンパイルされていないコードを説明するコメントが含まれていることがよくあります/

これらは2つの異なる概念であり、同じ構文を強制することは間違いであると思います。

18
Jeff Dege

Cスタイルのコメントがネストしないという問題に加えて、#if 0でコードのブロックを無効にすると、コードの折りたたみをサポートするエディターを使用している場合に折りたたむことができるという利点があります。また、どのエディターでも非常に簡単に実行できますが、C++スタイルのコメントでコードの大きなブロックを無効にすると、エディターのサポートやマクロがないと扱いにくい場合があります。

また、多くの#if 0ブロックにもelseブロックがあります。これにより、2つの実装/アルゴリズムを簡単に入れ替えることができ、1つのセクションを大規模にコメントアウトして別のセクションを大規模にコメント解除するよりも間違いなく間違いが少なくなります。ただし、そのイベントでは#if DEBUGなどの読みやすいものを使用した方がよいでしょう。

6
bta

これはかなり慣用的なCです。何が悪いのかわかりません。これは美しいコードではありませんが、読みやすく、コンテキストがなくても、何が起こっているのか、またその理由は明らかです。

変数名の方が優れている可能性があり、snprintfまたはstrncpyを使用する方がおそらく安全です。

あなたがそれがより良いかもしれないと思うなら、あなたはそれがどのように見えることを好みますか？

私は少し変更を加えるかもしれません：

char username[32];
strncpy(username, 30, (pwbuf ? pwbuf->pw_name : user_id));
username[31] = '\0';
3
Steven Schlansker

//を使用したブロックコメントに関する限り、私が考えることができる1つの理由は、そのコードをソース管理システムにチェックインすると、非難ログがそれらのコード行の最後のエディターとして表示することです。おそらくコメントはあなたに帰属させたいものですが、同時にコード自体もあなたに帰属させられています。もちろん、コードの「実際の」作成者の非難ログをチェックする必要がある場合は、前のリビジョンに戻って確認できますが、現在のリビジョンでその情報を保存しておくと時間を節約できます。

3
Aaron Klotz

明らかに、この種のことについては誰もが独自の意見を持っています。これが私のものです：

私はnever上記のようなコードを書き、そうした人をあまり考えません。スコープブレースなしで逃げても大丈夫だと思って噛まれた回数は数えられません。

制御ステートメントをコードブロックと同じ行に置くと、さらに悪くなります。インデントがないと、読み取り中にフロー制御を確認することが難しくなります。数年間コーディングを行った後は、特定の視覚的な手掛かりに頼ることができる限り、コードをすばやく正確に読み取って解釈できることに慣れます。 「特別な場合」のこれらの手がかりを回避することは、読者が停止してダブルテイクを行わなければならないことを意味します。

一方、#if (0)は開発中は問題ありませんが、コードが「安定」したら（または少なくとも0に意味のあるプリプロセッサシンボル名を付けます）。

1
Oliver Charlesworth

すごい！過剰反応しないでください...

私はそれを他の何よりも一貫性のない間隔のためにそれをだらだらと呼びます。短いステートメントをIFと同じ行に置く方が良いと思う時間はありましたが、それらのステートメントはそれを拡張しています。

インラインスタイルは、垂直方向に簡潔にするために優れています...簡単に4つに分割できます。

if (pwbuf) 
  sprintf(username,"%s",pwbuf->pw_name); 
else 
  sprintf(username,"%d",user_id);

次のスタイルは長すぎるので個人的には嫌いで、ファイルをスキミングするのは難しいです。

if (pwbuf) 
{
  sprintf(username,"%s",pwbuf->pw_name); 
}
else
{ 
  sprintf(username,"%d",user_id); 
}
0
smdrager

上記のポイント。しかし、モニターはワイドスクリーンであり、最近では、私は気にしません

if (pwbuf) sprintf(username,"%s",pwbuf->pw_name);
else       sprintf(username,"%d",user_id);

画面には常に水平方向のスペースが多すぎ、垂直方向のスペースが足りないようです。

また、コードブロックに既にプリプロセッサディレクティブがある場合は、#if 0;を使用しないでください。コードにすでにブロックコメントがある場合は、/* */を使用しないでください。すでに両方がある場合は、 ctrl+/、たくさんの行をコメントアウトする。そうでない場合、あなたは詰め込まれています、コードを完全に削除してください！

0
Sanjay Manohar
if ( pwbuf ) sprintf(username,"%s",pwbuf->pw_name);
else sprintf(username,"%d",user_id);

慣用的で簡潔。 2、3回以上触れた場合は、ブラケットして次の行に入れます。ロギング情報やその他の条件を追加する場合、それはあまり維持できません。

#if 0
....
#endif

デバッグコードのブロックをオンにするかどうかに適しています。また、この種のものをコメントアウトすることをブロックしようとすることに関連するコンパイルエラーを回避します：

/* line comment */
...
/* line comment again */

Cブロックのコメントはネストしないので。

0
Paul Nathan

コードの対称性をサポートし、行が長くなりすぎない場合は、より簡潔なスタイルを使用することがあります。次の不自然な例を見てみましょう。

if (strcmp(s, "foo") == 0)
{
    bitmap = 0x00000001UL;
    bit = 0;
}
else if (strcmp(s, "bar") == 0)
{
    bitmap = 0x00000002UL;
    bit = 1;
}
else if (strcmp(s, "baz") == 0)
{
    bitmap = 0x00000003UL;
    bit = 2;
}
else if (strcmp(s, "qux") == 0)
{
    bitmap = 0x00000008UL;
    bit = 3;
}
else
{
    bitmap = 0;
    bit = -1;
}

簡潔なバージョン：

if      (strcmp(s, "foo") == 0) { bitmap = 0x00000001UL; bit = 0;  }
else if (strcmp(s, "bar") == 0) { bitmap = 0x00000002UL; bit = 1;  }
else if (strcmp(s, "baz") == 0) { bitmap = 0x00000003UL; bit = 2;  }
else if (strcmp(s, "qux") == 0) { bitmap = 0x00000008UL; bit = 3;  }
else                            { bitmap = 0;            bit = -1; }

バグはあなたの顔にまっすぐ飛び込む可能性がはるかに高いです。

免責事項：私が言ったように、この例は不自然なものです。 strcmp、マジックナンバーの使用について、およびテーブルベースのアプローチの方が良いかどうか、お気軽にご相談ください。 ;）

0
Secure