Cヘッダーファイルの順序
多くのプロジェクトと例で、ローカルインクルードが外部ライブラリの前と組み込みコンパイラ機能のヘッダーファイルの前にリストされていることがわかります。
私が見逃している利点はありますか？
私は常に次のモデルを使用しました：
1) built in header files
2) External lib header file
A) External lib dependent on previous lib header file
3) custom project libs
4) local project header files
例えば：
#include <stdio.h>
#include <stdlib.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <SDL2/SDL_ttf.h>
#include "DisplayInfo.h"
#include "projectModule.h"
これは間違っている、または悪い習慣ですか？
ここに欠けている利点はありますか？
はいあります。私は、多数のソフトウェアプロジェクトと一緒に、質問で概説されているプラクティスに従っていました。現在取り組んでいるプロジェクトを含む多くのプロジェクトは、ソースファイルで反対のアプローチを取っています。
- ソースファイルで定義されている関数を宣言するヘッダーファイルが最初にインクルードされます。
- 同じプロジェクトの他のヘッダーファイルが次に含まれます。
- 非標準プロジェクト（eigen、boost、Qtなど）のヘッダーファイルは、ローカルヘッダーの後に含まれます。
- 最後に、標準ヘッダーファイルが最後に含まれます。
- ヘッダーが上記の順序に含まれなかった理由に関して、順不同のインクルージョンを明確に文書化する必要があります。
理想的には、すべてのヘッダーファイルは自己完結型であり、インクルードの順序は重要ではありません。実際には、多くの場合、自己完結型ではないヘッダーファイルを作成します。インクルードの順序が問題になることもあります。最初のインクルードファイルに対処するには、最初にインクルードされるファイルがソースファイルで定義されている関数を宣言するヘッダーファイルであることにより、ヘッダーファイルが実際に自己完結型であるという素晴らしいテストを作成します。最初にインクルードされたファイルに起因するコンパイルエラーは、そのヘッダーにバグがあることを意味します。
2番目の問題（順不同のインクルードが必要です）に対処するには、コードのにおいとして見なす必要があります。コードのにおいがあなた自身のプロジェクトコードにある場合、それを修正するのが最善の方法です。コードのにおいは、臭いが必要な場合があります。たとえば、ヘッダーファイルが自己完結型ではないという事実がなければ、他の方法では優れたサードパーティライブラリになるものを使用しているとします。すべての代替案はより悪いのでライブラリを使用しますが、順序が正しくない包含を文書化します。
この後者の問題は、プロジェクトがインサイドアウトのインクルージョンプラクティス（ローカルが最初、システムが最後）を採用するにつれて、よりまれになっています。その古いスタイルのインクルード順序はソフトウェアの品質を損ないます。
いいえ、インクルードの順序は悪い習慣ではありません。
ローカルヘッダーファイル、特に定義が現在のファイルにある関数を宣言するファイルを最初に置くことの利点の1つは、ヘッダーファイルが自己完結型であることを保証できることです（他のヘッダーファイルに依存していません）。それらの前に含まれています）。
それ以外は、インクルードの順序は主にローカルの習慣と個人的な好みの問題です。