これを100％確実に行うアルゴリズムはありません。コメントが何であっても、コンパイル可能なCOBOLコードである可能性があるためです。したがって、理論的には、コメントが無視された場合に1つのことを意味し、コメントがCOBOLの一部として扱われた場合に完全に別のことを意味するプログラムを作成できます。
しかし、それは非常にありそうにありません。最も起こりそうなことは、間違った規則の下でコードをコンパイルしようとすると、単に失敗するということです。したがって、これを行う唯一の正確な方法は、プログラムを一方向にコンパイル/解析してみることです。意味をなさない行に到達した場合は、別のスタイルに切り替えてください。スタイルがすでにわかっている場合は、コンパイラへの引数の受け渡しをサポートすることもできます。
説明したようなヒューリスティックを使用してみることができますが、それが完全に正確になることはありません。彼らがあなたに与えることができる最も多くは、コードがどちらかのスタイルである確率であり、それは彼らがより多くのコード行を調べるにつれて増加します。これらは、コンパイルを開始する前にスタイルを推測するのに役立つ場合や、問題が実際にコードのタイプミスである場合を把握する場合に役立ちます。
編集：
ヒューリスティックのアイデアに関しては、言うのは難しいです。//のような、または他の言語の標準的なコメントシジルがあった場合#、これははるかに簡単になります（実際にはありますが、コードがこの規則に準拠していないようです）。私が考えることができる唯一のことは、すべての行（または行の99％で、空の行やコメント付きの行を数えない*）に72桁目の前にピリオドがあるかどうかを確認することです。
実行したくないことの1つは、位置72以降の部分にヒューリスティックを適用することです。つまり、コメントをチェックして、それらが有効なCOBOLであるかどうかを確認する必要はありません。最初にCOBOLであることがわかっていることを確認し、それが単独で機能するかどうかを確認します。これにはいくつかの理由があります。
- 英語で書かれたコメントにはピリオドと引用符が含まれている可能性が高いため、最初と2番目の箇条書きが出ています。
- 自然言語は、COBOLのようなものよりも解析がはるかに困難です。
- コメントには、簡単にCOBOLを含めることができます（前のバージョンの行を誰かがコメントアウトした可能性があります）。
- コメントの重要なルールは、プログラムの動作に影響を与えてはならないということです。コメントを変更すると、プログラムのコンパイル方法が変わる可能性がある場合は、違反します。
そのすべてを念頭に置いて、私の意見では、ヒューリスティックをまったく使用しないでください。明示的に指定されていない限り、常に両方の規則に従ってプログラムをコンパイルするようにしてください。両方の規則でコードが正常にコンパイルされる可能性があります。そうすると、2つの異なるプログラムが作成され、どちらが正しいかを判断する方法がなくなります。
その場合は、2つの結果を（おそらくハッシュなどで）比較して、それらが同じプログラムであるかどうかを確認する必要があります。それらが同じである場合は素晴らしいですが、そうでない場合は、ユーザーに規則を明示的に選択するように強制する必要があります。