グローバル変数の使用について私が目にする反対意見のほとんどは、複数のスレッドやスレッドの安全性などの問題に言及しているため、理にかなっています。
しかし、小さなシングル スレッドの非 OS のケースでは、どのような反論がありますか? 私の場合、問題があれば組み込みシステムを「C」で書いています。私はまた、この製品の唯一の開発者でもあります。
グローバル変数を削除するとコードが改善されるのはなぜですか?
(いくつかの回答を読んだ後、このシステムには動的メモリ割り当て (malloc など) がないことも指摘する必要があることに気付きました。すべてのメモリはコンパイル時に静的に割り当てられます。)
そうではありません。
グローバル変数に関する 2 つの基本的な問題は、単純に名前空間が乱雑になることと、「誰も」それらを「制御」できないという事実です (したがって、衝突や複数のスレッドとの競合が発生する可能性があります)。
「グローバルは悪い」とは、他のほとんどすべてのコンピューター プログラミング イディオムがガイドラインであり、厳密で迅速なルールではないのと同様です。この種の「ルール」を作成するときは、単純にルールを適用するのではなく、ルール作成の背後にある状況と動機を理解するのが最善です。それらを盲目的に受け取らないでください。
あなたの場合、システムの性質とルールに関する議論を理解しているようで、この場合は適用しないと判断しました。そうです、そうではありません。
ですから、心配しないでください。
Cで記述された小さな組み込みアプリケーションでは、グローバル変数が必要です。たとえば、割り込みサービスルーチンと別のモジュールの間で情報を渡すには、グローバル変数を使用する必要があります。これらは、組み込みアプリケーションでグローバル変数を効果的に使用するのに役立ついくつかのヒントです。
静的変数とグローバル変数を区別します。静的変数は、同じCファイル内のすべての関数から使用できます。これらは、C++クラスのプライベートメンバーに相当します。Cでは、コンパイラの仕事を自分で行う必要があります。staticキーワードを使用して、モジュールの外部で変数が誤って使用されないようにし、そのスコープを明確にします。変数の前にモジュールの名前を付けることができます。
グローバル変数（多くのCファイルで使用される）の命名規則に従います。それらがグローバルであることを明確に示してください。
多くのグローバル変数が必要な場合は、それらを構造体にバンドルすることを検討してください。
必要に応じて、volatileキーワードを使用します。これは、グローバル変数がISRによって変更される場合に必要です。
カップリングを最小限に抑えるためです。あなたのシステムは今は小さいかもしれませんが、働き続ければそうではないかもしれません。
グローバル変数を使用するコードは保守が困難です。メンテナーは、変数が何をするのかを正確に知る前に、システム内の変数のすべての使用を見つけなければならないからです。これにより保守が遅くなるため、可能な限り回避する必要があります。それだけです』
グローバル変数を使用すると、それらがいつどこで更新され、どのコードがその変数を更新するのかを知るのが難しいことがよくあります。誰がそれを更新できるか、または変数がどのように更新されるかについての制御はありません。
アプリケーションが小さい場合は追跡するのはそれほど難しくありませんが、アプリケーションが大きくなり、グローバル変数が増えるほど、アプリケーション コードはスパゲッティのようになります。
要するに、メンテナンスとデバッグの悪夢になります。
問題は、最後のコードのどのビットがグローバルの状態を変更したかを追跡することです。一般に、変数についてより簡単に推論できるように、変数を可能な限り最小の範囲内に保持する必要があります。
頭に浮かぶ理由の 1 つは、将来の保証です。現在、あなたの製品の開発者はあなただけかもしれませんが、後で他の人がそれを維持することも考えられます。もちろん、これはあなたの特定のケースでは当てはまらないかもしれません。
現在、あなたの製品は小さく整頓されているかもしれませんが、グローバル変数を使用しても全体的なデザインが複雑になったり読みやすさが損なわれたりすることはありませんが、製品がそれほど大きくなったり、別の製品に組み込まれたりすることはないと誰が言いますか? そして、別のメンテナ/開発者があなたのグローバル変数の使用を整理しなければならないことを神が禁じています。
もちろん、ここでグローバル変数を使用することもできます。プロジェクトがより複雑になってきたら、戻ってその一部を書き直すこともできます。(グローバル変数のことを少しでも覚えていれば) その作業を行うのは手間がかかりすぎると判断し、設計を手放す可能性が高くなります: この時点で問題が発生しています!
ですから、頭痛の種から解放され、将来を見据えて設計してください。今必要な仕事は、おそらく将来の生活を楽にするでしょう。
それでも納得できない場合は、このプロジェクトに取り組んでいる開発者を想像してみてください。彼らのコードに欠陥があり、最高裁判所の前で悪いプログラミング慣行の有罪判決を受けました。バグのある飲酒コードはソースレビューの重要性を反映しています