Resumen

Este verificador de código IA analiza una función o archivo pegado contra cuatro señales reales basadas en reglas: funciones mayores de 40 líneas, anidamiento más profundo de 4 niveles, densidad de TODO/FIXME y llamadas arriesgadas como JSON.parse o fetch sin try/catch. Devuelve una puntuación de 0 a 100 con un desglose línea por línea de qué se dedujo y por qué, completamente en tu navegador. Sin cuenta, sin carga, sin calificación de IA de caja negra, solo cuatro verificaciones que cualquier ingeniero de staff ejecutaría a simple vista.

Un Verificador de Código IA que Detecta Problemas Reales, No Impresiones

Pega una función o archivo. Obtén una puntuación de 0 a 100 basada en cuatro verificaciones que un ingeniero de staff ejecutaría a simple vista: longitud de función, profundidad de anidamiento, densidad de TODOs y manejo de errores, calculado en vivo en tu navegador mientras escribes.

Desarrollador escribiendo en un teclado mecánico con un diff de pull request abierto en monitores duales

Verificador de código IA

Pega una función o un archivo completo a continuación. La puntuación y el desglose se actualizan mientras escribes.

0 líneas · escaneado localmente, nada sale de tu navegador
--
Pega código para escanear

Se ejecuta completamente en tu navegador. Nada se carga.

    Cómo funciona

    Cuatro verificaciones, sin caja negra

    Estructura: longitud y anidamiento

    Las funciones se marcan como problemáticas más allá de 40 líneas, coincidiendo con el predeterminado max-lines-per-function de ESLint de 50 líneas con cierto margen. La profundidad de anidamiento se rastrea contando llaves en lenguajes delimitados por llaves, o un fallback basado en indentación para código estilo Python, y se marca como problemática más allá de 4 niveles de profundidad, el punto que la mayoría de guías de estilo consideran ilegibles.

    Manejo de errores

    El escáner busca llamadas arriesgadas: JSON.parse, fetch, await, .then, execSync, requests., os.system. Luego verifica si existe un try/catch en algún lugar del código pegado. Una llamada arriesgada sin protección cercana significa una deducción, no un pase libre.

    Mantenimiento del código

    Los marcadores TODO, FIXME, XXX y HACK se cuentan y normalizan por cada 100 líneas de código. Uno o dos en un archivo es ingeniería normal. Una acumulación densa de ellos es una señal de que el archivo necesita revisión antes de enviarlo, no después.

    Por qué estas cuatro verificaciones, y no un linter real

    ESLint, pylint y sus equivalentes analizan un árbol de sintaxis abstracta, que es por eso que pueden detectar variables no usadas, ramas inaccesibles y conflictos de tipo. Esta herramienta no hace eso. Es un escáner de texto que puedes ejecutar en un fragmento sin pasos de compilación, archivo de configuración ni instalación, útil para los diez segundos entre terminar una función y abrir una solicitud de extracción. La compensación es honesta: menos verificaciones, más gruesas, calculadas de forma transparente, versus el análisis estático más profundo pero más lento de un linter real. Si un equipo ya ejecuta ESLint o pylint en CI, sigue ejecutándolo. Esta herramienta es para el vacío antes de eso, cuando el código aún no está en un repositorio.

    Preguntas sobre la puntuación

    ¿Es este verificador de código IA realmente gratuito?
    Sí. Se ejecuta completamente en tu navegador sin registro, sin clave de API y sin límite de uso. No hay servidor involucrado en la puntuación, por lo que no hay nada que contar o cobrar.
    ¿Se carga mi código en algún lugar?
    No. El escaneo se ejecuta como JavaScript simple en tu pestaña, contra el texto en el campo de texto. Nada se envía a un servidor, se almacena o registra, excepto un evento anónimo de ejecución de herramienta sin contenido de código, utilizado solo para ver que se utilizó el widget.
    ¿Qué cuenta como un verificador de código IA aquí, versus un linter real?
    Este es un escáner heurístico, no un compilador o linter como ESLint o pylint. No analiza un AST, por lo que no puede detectar errores de tipo, variables no usadas o rutas de código muertas. En su lugar, marca cuatro patrones estructurales: funciones largas, anidamiento profundo, densidad de TODO y llamadas arriesgadas sin try/catch cercano.
    ¿Con qué lenguajes funciona?
    Cualquier lenguaje delimitado por llaves funciona bien: JavaScript, TypeScript, Java, C, C#, Go, Rust, PHP, Swift. El anidamiento se mide contando llaves emparejadas. Los lenguajes que usan solo indentación como Python se remiten a una verificación de profundidad de indentación en su lugar. Las tabulaciones y espacios mixtos, o el formato poco convencional, pueden afectar el recuento de anidamiento de cualquier forma.
    ¿Por qué se marcó una función que creo que está limpia?
    Generalmente una de dos cosas: una llamada JSON.parse, fetch o await sin try/catch en ningún lugar del fragmento pegado, o anidamiento que va más allá de 4 niveles de profundidad en algún lugar del bloque. Pega más contexto, incluyendo el bloque try circundante si existe, y la puntuación se actualiza en vivo mientras escribes.
    ¿De dónde vienen los umbrales (40 líneas, profundidad 4, etc.)?
    Rastrean los valores predeterminados comunes en configuraciones de linters reales: la regla max-lines-per-function de ESLint tiene un predeterminado de 50 líneas, y la mayoría de guías de estilo internas marcan anidamiento más allá de 3 a 4 niveles como un problema de legibilidad. Establecemos los nuestros un poco por debajo de esos valores predeterminados, en el lado estricto, porque un escáner sin análisis completo de AST necesita un margen de seguridad más amplio que un linter real.
    ¿Puede esto reemplazar una revisión de código?
    No, y no debería intentarlo. Es una verificación rápida de cinco segundos antes de abrir una solicitud de extracción, no un revisor. Detecta problemas estructurales, no errores de lógica, problemas de seguridad o problemas de arquitectura. Úsalo antes de la revisión, no en su lugar.
    Mi puntuación es 100 pero el código aún se siente desorganizado. ¿La herramienta está equivocada?
    Está verificando cuatro cosas específicas, no la calidad general del código. Una puntuación de 100 significa que no hay funciones largas, no hay anidamiento profundo, no hay acumulación de TODO y no hay llamadas arriesgadas sin protección. No significa que los nombres sean buenos, que existan pruebas o que la arquitectura tenga sentido en seis meses.
    ¿Sesgar la puntuación pegando un fragmento parcial?
    Sí, y es lo esperado. Si pegas un cuerpo de función sin el try/catch que lo envuelve en otro lugar del archivo, el verificador no tiene forma de saber que esa protección existe. Para una lectura precisa, pega la unidad más pequeña autocontenida: una función o un archivo.

    Esto verifica la estructura. CodebaseChat responde la pregunta más difícil.

    Pregunta a tu base de código cualquier cosa en lenguaje natural: dónde está cableada la autenticación, por qué existe una función, qué llama a qué entre repositorios. Sin grep requerido.