Perlファイルに対して「浅い」構文チェックを実行するにはどうすればよいですか。この標準perl -c
は便利ですが、インポートの構文をチェックします。これは、コードリポジトリで作業して実行環境にプッシュし、リポジトリに関数が定義されているがまだ実行環境にプッシュされていない場合は、便利な場合もありますが、あまり良くありません。参照システムパスをインポートするため、関数のチェックに失敗します(つまり、Custom :: Project :: Lib qw(foo bar baz)を使用します)。
5 に答える
インポートには、後続のコードの解析に影響を与える機能があるため、実際には実行できません。たとえばuse strict
、裸の単語が文字列として解析されないようにし (そして、変数名の使用方法に関する規則を変更します)、use constant
定数サブルーチンを定義させ、、、またはuse Try::Tiny
を含む式の解析を変更します(それらにプロトタイプを与えることによって) . より一般的には、呼び出し元の名前空間に何かをエクスポートするモジュールは解析に影響を与える可能性があります。これは、名前が既存のサブルーチンを参照している場合とそうでない場合とで、perl パーサーが異なる方法であいまいさを解決するためです。try
catch
finally
&
これには2つの問題があります。
-c
必要なモジュールが欠落している場合に失敗しないようにするにはどうすればよいですか?2つの解決策があります:
A.本番環境でフェイク/スタブモジュールを追加する
B.すべてのモジュールで、特別なキャッチオール@INCサブルーチンエントリを使用します(でのサブルーチンの使用については、ここ
@INC
で説明します)。これには明らかに、ライブラリが欠落している場合にモジュールが実際の本番ランタイムで失敗しないという問題があります-私の本ではDoublePlusNotGoodです。欠落しているモジュールでの失敗をなんとかスキップできたとしても、欠落しているモジュールからインポートされた、またはそのモジュールの名前空間から明示的に使用された識別子の使用では失敗します。
これに対する唯一の現実的な解決策は、#1aに戻って偽のスタブモジュールを使用することですが、今回は、すべてのパブリックインターフェイスに対して宣言され(必要に応じて)エクスポートされた識別子を持っています。たとえば、何もしないサブまたはダミー変数。
ただし、それでも、独自の名前空間に何を作成し、実行時に何をエクスポートするかを動的に決定する一部の高度なモジュールでは失敗します(呼び出し元のコードは、呼び出すサブを動的に決定できます-一体、場合によってはインポートするモジュール)。
ただし、このアプローチは、静的に名前が付けられた事前定義されたパブリックサブ、メソッドを呼び出し、エクスポートされた変数にアクセスする通常の「Java/Cのような」OOまたは手続き型コードに対しては問題なく機能します。
コード リポジトリを構文チェックに含めることをお勧めします。perl -I/path/to/working/code/repo/local_perl/ -c
またはPERL5LIB=/path/to/working/code/repo/local_perl/
実行前に設定しますperl -c
。どちらのオプションでも、実際のコードと同様のディレクトリ構造にあると仮定して、作業コードをチェックできるはずです。
ホームフォルダーに不足しているライブラリのスタブを作成できると思います。