Quelqu'un connaît-il un validateur Perl

Question

Je suis très novice en Perl et je viens de commencer à travailler avec lui après avoir appris JavaScript au départ. Je me demande s'il existe un validateur pour vérifier le code Perl (comme Firebug pour JS). Si quelqu'un en connaît un fiable, ce serait très apprécié. J'ai fait de nombreuses recherches sur Google sans grand succès et, comme nous le savons tous, l'apprentissage d'une nouvelle langue est synonyme d'erreurs. Merci d'avance !

Answer 1

Qu'en est-il de Perl lui-même ?

perl -c your_program.pl

Si vous ajoutez les éléments suivants au début de vos programmes, vous éviterez de nombreux maux de tête.

use strict;
use warnings;
use diagnostics;

Enfin, il y a Perl::Critic .

Answer 2

voici un validateur perl en ligne

Pour vérifier simplement si la syntaxe est propre, vous pouvez essayer perl -c filename . Pour nettoyer le code au niveau du format, vous pouvez regarder dans PerlTidy . . Vous n'avez peut-être pas besoin d'un vaidator. Vous pouvez faire certaines choses vous-même.

REDIRECTION DES MESSAGES D'ERREUR

Par défaut, les messages d'erreur sont envoyés à STDERR. La plupart des serveurs HTTPD dirigent STDERR vers le journal des erreurs du serveur. Certaines applications peuvent souhaiter conserver des journaux d'erreurs privés, distincts du journal d'erreurs du serveur, ou bien diriger les messages d'erreurs vers STDOUT afin que le navigateur les reçoive.

En carpout() est prévue à cet effet. Puisque carpout() n'est pas exporté par défaut, vous devez l'importer explicitement en disant

 use CGI::Carp qw(carpout);

La fonction carpout() requiert un argument, qui doit être une référence à un fichier ouvert pour les erreurs d'écriture. Elle doit être appelée dans un bloc BEGIN au début de l'application CGI pour que les erreurs de compilation soient détectées. Exemple :

 BEGIN {
    use CGI::Carp qw(carpout);
    open(LOG, ">>/usr/local/cgi-logs/mycgi-log") or
    die("Unable to open mycgi-log: $!\n");
    carpout(LOG);
    }

carpout() ne gère pas le verrouillage des fichiers sur le journal pour vous à ce stade. Notez également que carpout() ne fonctionne pas avec les gestionnaires de fichiers en mémoire, bien qu'un correctif soit le bienvenu pour résoudre ce problème.

Le vrai STDERR n'est pas fermé -- il est déplacé vers CGI::Carp::SAVEERR. Certains serveurs, lorsqu'ils traitent avec des CGI scripts, ferment leur connexion au navigateur lorsque le scripts ferme STDOUT et STDERR. CGI::Carp::SAVEERR est là pour empêcher que cela ne se produise prématurément.

Vous pouvez passer des chemins de fichiers à carpout() de différentes manières. La manière "correcte" est de passer une référence à un fichier GLOB :

carpout(*LOG) ;

les syntaxes suivantes sont également acceptées :

carpout(LOG);
carpout(main::LOG);
carpout(main'LOG);
carpout(\LOG);
carpout(\'main::LOG');
... and so on

FileHandle et d'autres objets fonctionnent également.

FAIRE APPARAÎTRE LES ERREURS PERL DANS LA FENÊTRE DU NAVIGATEUR

Si vous voulez envoyer des erreurs fatales (die, confess) au navigateur, demandez à importer la sous-routine spéciale "fatalsToBrowser" :

 use CGI::Carp qw(fatalsToBrowser);
    die "Bad error here";

Les erreurs fatales seront désormais répercutées dans le navigateur ainsi que dans le journal. CGI::Carp s'arrange pour envoyer un en-tête HTTP minimal au navigateur, de sorte que même les erreurs qui se produisent au début de la phase de compilation seront vues. Les erreurs non fatales seront toujours dirigées vers le fichier journal uniquement (sauf si elles sont redirigées avec carpout).

*Notez que fatalsToBrowser ne fonctionne pas avec mod_perl version 2.0 et supérieure.*

Modification du message par défaut

Par défaut, le message d'erreur du logiciel est suivi d'une note invitant à contacter le Webmaster par e-mail en indiquant l'heure et la date de l'erreur. Si ce message n'est pas à votre goût, vous pouvez le modifier en utilisant le bouton set_message() routine. Elle n'est pas importée par défaut ; vous devez l'importer sur la ligne use() :

use CGI::Carp qw(fatalsToBrowser set_message);
set_message("It's not a bug, it's a feature!");

Vous pouvez également transmettre une référence de code afin de créer un message d'erreur personnalisé. Au moment de l'exécution, votre code sera appelé avec le texte du message d'erreur qui a provoqué la mort du script. Exemple :

use CGI::Carp qw(fatalsToBrowser set_message);
BEGIN {
sub handle_errors {
my $msg = shift;
print "<h1>Oh gosh</h1>";
print "<p>Got an error: $msg</p>";
}
set_message(\&handle_errors);
}

Answer 3

Parce que perl est un langage dynamique, il y a beaucoup de choses qu'il n'est pas possible de valider ; par exemple, vous pouvez appeler un sous qui n'existe pas au moment de la compilation, car il pourrait être créé pendant l'exécution. Il n'y a aucun moyen pour un validateur statique de savoir si l'appel est correct ou non.

Si tout ce que vous voulez savoir est si le code se compile, utilisez l'interpréteur perl lui-même.

Si vous voulez vérifier que le code respecte des normes de codage données, utilisez la méthode suivante Perl::Critic .

Answer 4

Il existe de nombreuses façons de s'attaquer à ce problème. Vous pouvez lire http://perldoc.perl.org/perldebug.html pour apprendre à utiliser le débogueur, qui, à certains égards, est similaire à Firebug. Mais il existe de nombreuses autres façons d'éviter automatiquement les problèmes.

1. De nombreuses classes d'erreurs courantes sont caug utiliser strict ; utiliser des avertissements ;

2. http://perltidy.sourceforge.net/ reformate votre code et rendra de nombreuses erreurs courantes faciles à détecter.

3. Le module CPAN Perl::Critic effectue une analyse automatisée du code afin d'appliquer des décisions de style particulières. Un style cohérent rend les erreurs plus faciles à repérer.

4. Utilisez des tests unitaires. Le module de base Test::More permet de s'y mettre facilement.