これは Xcode とは関係ありませんが、コンパイラとは関係ありません。Apple がこの制限を追加したのではなく、コンパイラは Apple のものではなく、OpenSource プロジェクト ( GCCおよびLLVM/clang ) です。
100 個の返品ステートメントを修正するのに 2 時間かかった理由をお尋ねしてもよろしいですか? そのような return ステートメントを 100 個修正するのに 5 分以上かかることはありません。
- どこかに書い
return 0;
て、それを選択して、クリップボード ( ) にコピーして、CMD+C
もう一度削除します。
- どこ
return;
かに書き込んで選択し、ヒットCMD+E
して検索バッファにコピーし、もう一度削除します。
- ソースコードに移動します。
CMD+G
「次を探す」という意味のヒット。
- 見つかった式がエラーとしてマークされていない場合は、(4) に進みます。
CMD+V
で上書きreturn;
するヒット(貼り付け) return 0;
。
- (4)にたどり着きました。
CMD+G
したがって、基本的には、ファイルをジャンプするためにヒットし続けCMD+V
、エラーが表示されるたびに. 次のファイルにすばやく移動するには、Xcode でエラー ビューを開きます。

最初のファイルの最初のエラーを選択し、CMD+G
手順がファイルの最後に到達するたびCMD+'
に、リストの次のファイルの最初の問題にジャンプする を押します。開発者として、キーボードをより効果的に使用する方法を実際に学ぶ必要があります。キーボードに手を置いておくと、キーボードとマウス/タッチパッド/トラックボールなどの間を行き来するよりも、何百倍も生産性が向上します。
そして、コード行の量 (「20,000 行を超えるコード」) はどのように関連しているのでしょうか? 関連するのは返品明細書の量です。
あなたのコードは現在深刻に壊れています。この壊れたコードをコンパイルする方法を考えるのに時間を費やすのではなく、修正することを強くお勧めします。一度修正されると、永久に機能し、次回コンパイラが更新されて最後のハックが機能しなくなったときに再び壊れることはありません。
つまり、return のみを入力した場合、ブール値または int 値を返すメソッドに対して何を返したいかをコンパイラがどのように知るのでしょうか? 提案された「return 0;」数値 (浮動小数点を含む) とブール値 (0 = false/NO) を返すすべてのメソッドで機能し、コンパイラを再び満足させます。その場合、古代の C コンパイラによって返されたのと同じ値です。
Xcode 3.1 でさえ、これらの return ステートメントはあらゆる場所で警告を生成する必要があることに注意してください。真面目な開発者として、常にすべての警告をエラーとして扱います。プロジェクトに警告は表示されません。警告は、何か問題があるか、少なくとも何か問題がある可能性があることを示しており、それは、外に出て修正する必要があることを意味します。コードを変更することで、ほとんどすべての警告を消すことができます。そのため、コンパイラで警告を無視したり無効にしたりするのではなく、警告を修正してください。今日、多くの企業はゼロ警告ポリシーを採用しており、コードが 1 つの警告しか生成しない場合、そのコードは拒否されます。このコードの作成者がすべての警告をエラーとして扱っていた場合、それらを修正する必要はありません。