2

最近、C 言語について自分自身をリフレッシュしました。いくつかのブログから、「==」や「&&」などの演算子は、プログラマーが代わりに「=」と「&」をそれぞれ使用するエラーが発生しやすく、プログラマーが問題を見つけて修正するのに多くの時間を費やしていることを読みました。 .

「==」と「&&」のマクロを定義すると問題が解決すると思います。

#define EQ ==
#define AND &&

int main(void) 
{
    int a = 1 , b = 2 ; 

    if(a EQ 1 AND b EQ 2 ){
        //  some statements
    }

}

それは読みやすさを混乱させていますか？この問題を解決する他の解決策はありますか?

4

5 に答える 5

3

個人的には、C のキーワードや演算子を置き換えるマクロの作成など、言語の非常に基本的な構文には触れたくないのです。

この場合、それは非常に単純であり、可読性はあまり変わらないかもしれませんが、他のプログラマー (コードを保守しているのがあなただけではない場合) は、それらのマクロを見て、あいまいまたはエラーであると思われる別のマクロを作成するように誘惑される可能性があります。傾向がある。

したがって、C のキーワード/演算子レベルでマクロを推奨するつもりはありません
。

  gcc -Wall prog.c -o prog

すべての警告をWall有効にします (gcc で警告を絞り込むことができます)。これは、使用しているコンパイラによって異なります。

例えば

  int a=1,b=2;
  if (a = b) { ... }

オプション付きのコンパイラとして gcc を使用すると、警告が表示され-Wallます。

于 2013-01-09T07:19:33.180 に答える
1

C 言語を再定義しようとすることは、常に非常に悪い考えです。マクロを使用して演算子を置き換えると、他の C プログラマーがコードを読めなくなります。

&& が誤って & になってしまうことについては、問題があるとは思えません。少なくとも、その問題に遭遇したことはありません。標準 C には代替論理演算子が既にあります。どちらかといえば、それらを使用する必要があります。

ヘッダー<iso646.h>は、対応するトークン (右側) に展開される次の 11 個のマクロ (左側) を定義します。

and     &&
and_eq  &=
bitand  &
bitor   |
compl   ~
not     !
not_eq  !=
or      ||
or_eq   |=
xor     ^
xor_eq  ^=

== が危険であるという考えは、ひどく時代遅れの考えです。80 年代、混乱したプログラマーは、「比較を行うときは常にリテラルを変数の前に置く」、つまりif (0 == var).

これに関連するバグを回避する正しい方法は、条件内での代入を避けることです。それを良いコーディング スタイルとして採用すれば、そのようなバグを回避するのは簡単です。1990 年に Turbo C がリリースされて以来、それらを見つけることは問題ではありませんでした。それ以来、ほとんどすべてのコンパイラは、if ステートメント内で代入を行ったときに、「誤った代入の可能性」について警告することができました。

現代のプログラミングでは、すべてのプロのプログラマーが静的アナライザー ツールを使用して、あらゆる種類のコンパイル時のバグを見つけます。何らかの理由でコンパイラがこのバグを検出できない場合、静的アナライザは確実に検出します。

したがって、あなたの質問に答えるには:はい、それは乱雑であり、コードがエラーを起こしやすくなり、読みにくくなります。

于 2013-01-09T07:25:47.743 に答える
1

最善の方法は、すべての警告フラグを有効にしてコンパイルし (-Wall)、警告なしでコードをコンパイルできることを確認することです。

そしてTDD。構文の実践についての詳細です

「コードコンプリート」という本をお勧めします

于 2013-01-09T07:17:44.483 に答える
0

いいえ、特に良い考えではありません。つまり、コードを読む経験豊富な C プログラマーは、コードを読む前に、その内容EQとAND意味を理解する必要があります。

確かに、==エラーが発生しやすい可能性がありますが、その問題に対する私見の最善の解決策は、(a) コンパイラで警告をオンにし、(b)注意することです。

(標準ヘッダーはに展開される<iso646.h>マクロを提供しますが、 のマクロは提供しません。 のポイントは、より読みやすい代替を提供するためではなく、古い国別バリアント文字セットのために特定の文字を使用するのが難しいシステムをサポートすることでした。 .)and&&==<iso646.h>

于 2013-01-09T07:16:30.980 に答える
0

実際、ここに問題はないと思います。何か怪しいものが検出されると、最新のコンパイラは警告を発行します。

于 2013-01-09T07:16:45.953 に答える