Résumé

Ce vérificateur de code IA analyse une fonction ou fichier collé contre quatre signaux concrets et basés sur des règles : fonctions dépassant 40 lignes, imbrication au-delà de 4 niveaux, densité de marqueurs TODO/FIXME, et appels à risque comme JSON.parse ou fetch sans bloc try/catch. Il renvoie un score 0-100 avec une ventilation ligne par ligne des déductions et raisons, entièrement dans votre navigateur. Pas de compte, pas de téléchargement, pas de notation IA boîte noire — juste quatre analyses qu'un ingénieur sénior vérifierait à l'œil nu.

Un vérificateur de code IA qui note les vrais signaux d'alerte, pas les impressions

Collez une fonction ou fichier. Obtenez un score 0-100 construit à partir de quatre analyses qu'un ingénieur sénior vérifierait à l'œil nu : longueur de fonction, profondeur d'imbrication, backlog TODO, et gestion d'erreurs, calculés en direct dans votre navigateur au fur et à mesure que vous tapez.

Analysez votre code
Développeur tapant sur un clavier mécanique avec un diff de pull request ouvert sur deux écrans

Vérificateur de code IA

Collez une fonction ou un fichier entier ci-dessous. Le score et la ventilation se mettent à jour en direct au fur et à mesure que vous tapez.

0 lignes · analysé localement, rien ne quitte votre navigateur
--
Collez du code à analyser

Fonctionne entièrement dans votre navigateur. Rien n'est téléchargé.

    Comment ça marche

    Quatre analyses, pas de boîte noire

    Structure : longueur et imbrication

    Les fonctions sont signalées au-delà de 40 lignes, en accord avec le défaut max-lines-per-function d'ESLint de 50 avec une marge. La profondeur d'imbrication est suivie en comptant les accolades pour les langages à accolades, ou une fallback de profondeur d'indentation pour le code style Python, et signalée au-delà de 4 niveaux profonds, le point où la plupart des guides de style les appelle illisibles.

    Gestion d'erreurs

    Le scanner cherche les appels à risque : JSON.parse, fetch, await, .then, execSync, requests., os.system. Puis il vérifie si un try/catch existe quelque part dans le code collé. Appel à risque sans protection à proximité signifie une déduction, pas un laisser-passer.

    Maintenance du code

    Les marqueurs TODO, FIXME, XXX et HACK sont comptés et normalisés par 100 lignes de code. Un ou deux dans un fichier est un ingénierie normale. Un backlog dense d'entre eux est un signal que le fichier a besoin d'une passe avant l'expédition, pas après.

    Pourquoi ces quatre analyses et pas un vrai linter

    ESLint, pylint et leurs équivalents parsent un arbre de syntaxe abstraite, ce qui leur permet d'attraper les variables inutilisées, les branches inatteignables et les incompatibilités de type. Cet outil ne fait pas ça. C'est un scanner de texte que vous pouvez exécuter sur un extrait sans étape de build, sans fichier de config, et sans installation, utile pour les dix secondes entre la fin d'une fonction et l'ouverture d'une pull request. Le compromis est honnête : moins d'analyses, plus grossières, calculées de manière transparente, par rapport à l'analyseur statique plus profond mais plus lent d'un vrai linter. Si une équipe exécute déjà ESLint ou pylint en CI, continuez. Cet outil est pour l'écart avant ça, quand le code n'est pas encore dans un repo.

    Questions sur le score

    Ce vérificateur de code IA est-il vraiment gratuit ?
    Oui. Il fonctionne entièrement dans votre navigateur sans inscription, sans clé API, et sans limite d'utilisation. Il n'y a pas de serveur impliqué dans le scoring, donc rien à contrôler ni à facturer.
    Mon code est-il téléchargé quelque part ?
    Non. L'analyse s'exécute en JavaScript pur dans votre onglet, sur le texte assis dans la zone de texte. Rien n'est envoyé à un serveur, stocké ou enregistré, sauf un événement anonyme de lancement d'outil sans contenu de code, utilisé uniquement pour vérifier que le widget a été utilisé.
    Qu'est-ce qui constitue un vérificateur de code IA, par rapport à un vrai linter ?
    C'est un scanner heuristique, pas un compilateur ou un linter comme ESLint ou pylint. Il ne parse pas un AST, donc il ne peut pas attraper les erreurs de type, les variables inutilisées ou les chemins de code mort. Il signale quatre motifs structurels à la place : fonctions longues, imbrication profonde, densité TODO, et appels à risque sans try/catch à proximité.
    Quels langages cela fonctionne-t-il ?
    Tout ce qui est délimité par des accolades fonctionne bien : JavaScript, TypeScript, Java, C, C#, Go, Rust, PHP, Swift. L'imbrication est mesurée en comptant les accolades appariées. Les langages basés uniquement sur l'indentation comme Python reviennent à une vérification de profondeur d'indentation. Les tabs et espaces mélangés, ou le formatage inhabituel, peuvent dérégler le compteur d'imbrication de toute façon.
    Pourquoi une fonction que je pense être propre a-t-elle été signalée ?
    Généralement l'une de deux choses : un appel JSON.parse, fetch ou await sans try/catch nulle part dans l'extrait collé, ou une imbrication dépassant 4 niveaux profonds quelque part dans le bloc. Collez plus de contexte, y compris le bloc try entourant s'il existe, et le score se met à jour en direct au fur et à mesure que vous tapez.
    D'où viennent les seuils (40 lignes, profondeur 4, etc.) ?
    Ils suivent les défauts courants dans les configs réels de linter : la règle max-lines-per-function d'ESLint par défaut est 50 lignes, et la plupart des guides de style interne signalent l'imbrication au-delà de 3 à 4 niveaux comme un problème de lisibilité. Nous fixons les nôtres légèrement sous ces défauts, du côté strict, parce qu'un scanner sans parsing AST complet a besoin d'une marge de sécurité plus large qu'un vrai linter.
    Peut-il remplacer une revue de code ?
    Non, et il ne devrait pas essayer. C'est un contrôle rapide de cinq secondes avant d'ouvrir une pull request, pas un reviewer. Il attrape les odeurs structurelles, pas les bugs de logique, les problèmes de sécurité ou les problèmes d'architecture. Utilisez-le avant la revue, pas à la place d'une.
    Mon score est 100 mais le code me semble quand même désordonné. L'outil a-t-il tort ?
    Il vérifie quatre choses spécifiques, pas la qualité générale du code. Un score 100 signifie pas de fonctions longues, pas d'imbrication profonde, pas de backlog TODO, et pas d'appels à risque non gardés. Cela ne signifie pas que le nommage est bon, que les tests existent, ou que l'architecture a du sens six mois plus tard.
    Coller un extrait partiel fausse-t-il le score ?
    Oui, et c'est attendu. Si vous collez un corps de fonction sans le try/catch qui le enveloppe ailleurs dans le fichier, le checker n'a aucun moyen de savoir que cette garde existe. Pour une lecture précise, collez la plus petite unité autonome : une fonction, ou un fichier.

    Ceci vérifie la structure. CodebaseChat répond à la question plus difficile.

    Posez n'importe quoi à votre codebase en langage naturel : où l'auth est câblée, pourquoi une fonction existe, ce qui appelle quoi dans les repos. Pas de grep requis.

    Essayer CodebaseChat