もう一度: -1 に投票する場合は、理由を説明するコメントを残してください。この投稿は、このアプローチを承認するかどうかではなく、どのように実行するかについてです。
多くのアーキテクトと同様に、私は長年の経験を通じて開発者が遵守することを期待するコーディング標準を開発してきました。
これは特に、3 ～ 4 年の経験があればシニア レベルの開発者になると信じている人々にとっては大きな問題です。これをトレーニングとコード レビューの問題としてアプローチしても、成果は限定的です。
そのため、ビルド プロセスにカスタムのコンパイル時エラーを追加して、社内のベスト プラクティスとコーディング標準をより厳密に適用できるようになれば素晴らしいと考えていました。
たとえば、すべてのデータベース アクセスにストアド プロシージャを使用します。これにより、プロシージャ レベルのセキュリティ、データベースのカプセル化 (テーブル構造はアプリから隠されます)、およびその他の利点が提供されます。(注:これについて議論を始めるつもりはありません。) 一部の開発者は、インライン SQL またはパラメーター化されたクエリを好みますが、それは問題ありません - 自分の時間と自分のプロジェクトで。
たとえば、次のように見えるものをすべて見つけるコンパイルチェックを追加する方法が欲しい
string sql = "insert into some_table (col1,col2) values (@col1, @col2);"
エラーを生成するか、特定の状況では警告を生成し、次のようなメッセージを表示します。
Inline SQL and parametrized queries are not permitted.
または、var キーワードを使用する場合
var x = new MyClass();
Variable definitions must be explicitly typed.
Visual Studio と MSBuild は、この機能を追加する方法を提供していますか? 正規表現を使用して受け入れられないコードを見つけて正しいエラーを生成できると考えていますが、パフォーマンスの観点から、これをビルド プロセスに統合する最善の方法が何であるかはわかりません。
ビルド前またはビルド後のステップを追加してカスタム EXE を実行することはできますが、行固有およびファイル固有のエラーを返すにはどうすればよいでしょうか? また、リンク後ではなく、各ファイルのコンパイル後にこれを実行したいと思います。
このタイプのパターン マッチングを実行するには、正規表現が最適な方法ですか?それとも、解析ツリーを介してノードレベルの検証を可能にする C# パーサーを介してコードを実行する必要がありますか?
提案や以前の経験談をいただければ幸いです。
コメント 何人かの回答者は、ユーザーがストアド プロシージャ以外を実行する能力を db パーミッションによって制限できることを指摘しています。ただし、35 万行以上のアプリケーションを ASP 3.0 から ASP.NET MVC に移植する過程にあり、既存のコード ベースは連結 SQL に大きく依存していますが、新しいものはすべて Enterprise Library を使用しています。.NET コード用に別の Web ユーザー アカウントを追加して、アクセス許可をより制限することもできると思います。