Summary

To narzędzie do sprawdzania kodu skanuje wklejony kod pod kątem czterech rzeczywistych, opartych na zasadach sygnałów: funkcji ponad 40 linii, zagnieżdżenia przechodzącego 4 poziomy, gęstości TODO/FIXME, i ryzykownych wywołań takich jak JSON.parse czy fetch bez try/catch. Zwraca ocenę 0-100 wraz z szczegółowym rozbiorem tego co zostało odjęte i dlaczego, całkowicie w Twojej przeglądarce. Brak konta, brak przesyłania, brak oceny przez czarną skrzynkę AI — tylko cztery kontrole, które każdy starszy inżynier przeprowadzałby okiem.

Sprawdzanie kodu, które mierzy rzeczywiste problemy, nie przeczucia

Sprawdzanie kodu AI w 10 sekund. Wklej funkcję lub plik, otrzymaj ocenę 0-100 zbudowaną z czterech kontroli, które starszy inżynier przeprowadzałby okiem: długość funkcji, głębokość zagnieżdżenia, zaległy backlog TODO, i obsługa błędów. Ocena się aktualizuje na żywo w przeglądarce.

Zeskanuj kod
Deweloper pracuje przy mechanicznej klawiaturze z otwartym diff pull requesta na dualnych monitorach

Sprawdzanie kodu AI

Wklej funkcję lub cały plik poniżej. Ocena i rozkład aktualizują się na żywo.

0 linii · skanowanie lokalne, nic nie opuszcza Twojej przeglądarki
--
Wklej kod do skanowania

Działa całkowicie w Twojej przeglądarce. Nic nie jest przesyłane.

    Jak to działa

    Cztery kontrole, bez czarnej skrzynki

    Struktura: długość i zagnieżdżenie

    Funkcje są oznaczane jako problematyczne ponad 40 linii, zgodnie z domyślną regułą max-lines-per-function narzędzia ESLint (50 linii z marginesem). Głębokość zagnieżdżenia jest śledzona poprzez liczenie nawiasów klamrowych dla języków z nawiasami klamrowymi, lub fallback oparty na indentacji dla kodu w stylu Pythona, i jest oznaczana ponad 4 poziomy, punkt gdzie większość poradników stylu uważa to za nieczytelne.

    Obsługa błędów

    Skaner szuka ryzykownych wywołań: JSON.parse, fetch, await, .then, execSync, requests., os.system. Następnie sprawdza czy try/catch istnieje gdziekolwiek w wklejonym kodzie. Ryzykowne wywołanie bez ochrony oznacza odjęcie punktów, nie przepuszczenie.

    Gospodarka

    Znaczniki TODO, FIXME, XXX i HACK są zliczane i normalizowane na 100 linii kodu. Jedno lub dwa w pliku to normalna inżynieria. Gęsty backlog tych znaczników to sygnał że plik wymaga przejrzenia przed wysłaniem, nie po.

    Dlaczego te cztery kontrole, a nie prawdziwy linter

    ESLint, pylint i im podobne parsują abstrakcyjne drzewo składni, dlatego mogą wyłapać nieużywane zmienne, nieosiągalne gałęzie i niezgodności typów. To narzędzie tego nie robi. To skaner tekstu, który możesz uruchomić na wycięciu bez kroku kompilacji, pliku konfiguracyjnego i instalacji — przydatny przez dziesięć sekund między ukończeniem funkcji a otwarciem pull requesta. Kompromis jest szczery: mniej, bardziej ogólne kontrole, obliczane przejrzyście, kontra głębsza ale wolniejsza analiza statyczna. Jeśli Twój zespół już uruchamia ESLint lub pylint w CI, kontynuuj. To narzędzie jest na laskę przed tym, gdy kod nie jest jeszcze w repozytorium.

    Pytania o ocenę

    Czy to narzędzie do sprawdzania kodu jest naprawdę bezpłatne?
    Tak. Działa całkowicie w Twojej przeglądarce bez rejestracji, klucza API i limitu użycia. Nie ma serwera zaangażowanego w ocenę, więc nie ma nic do pomiaru ani fakturowania.
    Czy mój kod jest przesyłany gdziekolwiek?
    Nie. Skanowanie działa jako zwykły JavaScript w Twojej karcie, na tekście w polu tekstowym. Nic nie jest wysyłane do serwera, przechowywane ani rejestrowane, z wyjątkiem anonimowego zdarzenia uruchomienia narzędzia bez zawartości kodu, używanego tylko do sprawdzenia czy widget został użyty.
    Co liczy się jako sprawdzanie kodu tutaj, w porównaniu z prawdziwym linterem?
    To heurystyczny skaner, nie kompilator ani linter jak ESLint czy pylint. Nie parsuje AST, więc nie może wyłapać błędów typów, nieużywanych zmiennych czy martwych ścieżek kodu. Zamiast tego oznacza cztery wzorce strukturalne: długie funkcje, głębokie zagnieżdżenie, gęstość TODO i ryzykowne wywołania bez try/catch w pobliżu.
    Które języki to wspiera?
    Wszystko z nawiasami klamrowymi działa dobrze: JavaScript, TypeScript, Java, C, C#, Go, Rust, PHP, Swift. Zagnieżdżenie jest mierzone poprzez liczenie dopasowanych nawiasów klamrowych. Języki tylko z indentacją takie jak Python wracają do sprawdzenia głębokości indentacji. Mieszane tabulatory i spacje lub niezwykłe formatowanie mogą zaburzać liczenie zagnieżdżenia w każdym razie.
    Dlaczego funkcja którą uważam za czystą została oznaczona?
    Zwykle z dwóch powodów: wywołanie JSON.parse, fetch lub await bez try/catch gdziekolwiek we wklejonym wycięciu, lub zagnieżdżenie przechodzące 4 poziomy głębokie gdzieś w bloku. Wklej więcej kontekstu, łącznie z otaczającym blokiem try jeśli istnieje, i ocena aktualizuje się na żywo.
    Skąd się biorą progi (40 linii, głębokość 4 itd)?
    Śledzą wspólne domyślne ustawienia w rzeczywistych konfiguracjach linterów: reguła max-lines-per-function narzędzia ESLint domyślnie wynosi 50 linii, i większość wewnętrznych poradników stylu oznacza zagnieżdżenie ponad 3 do 4 poziomów jako problem czytelności. Nasze są ustawione nieco poniżej tych domyślnych, po stronie surowej, ponieważ skaner bez pełnego parsowania AST potrzebuje szerszego marginesu bezpieczeństwa niż prawdziwy linter.
    Czy to może zastąpić przegląd kodu?
    Nie, i nie powinno próbować. To pięciosekundowy sprawdzian intuicji przed otwarciem pull requesta, nie recenzent. Wyłapuje zapachy strukturalne, nie błędy logiki, problemy bezpieczeństwa czy problemy architektury. Używaj tego przed przeglądem, nie zamiast niego.
    Moja ocena to 100 ale kod wciąż wygląda bałaganiarsko. Czy narzędzie się myli?
    Sprawdza cztery konkretne rzeczy, nie ogólną jakość kodu. 100 oznacza brak długich funkcji, brak głębokich zagnieżdżeń, brak zaległości TODO, i brak niestrzeżonych ryzykownych wywołań. Nie oznacza że nazewnictwo jest dobre, testy istnieją, czy architektura ma sens za sześć miesięcy.
    Czy wklejenie fragmentu wycinka skośnie wpływa na ocenę?
    Tak, i to jest oczekiwane. Jeśli wkleiasz treść funkcji bez try/catch który ją otacza gdzieś indziej w pliku, skaner nie ma sposobu na poznanie że ta ochrona istnieje. Aby uzyskać dokładną ocenę, wklej najmniejszą samodzielną jednostkę: jedną funkcję, lub jeden plik.

    To sprawdza strukturę. CodebaseChat odpowiada na trudniejsze pytanie.

    Zapytaj swój kod o cokolwiek w zwykłym języku: gdzie jest okablowana autoryzacja, dlaczego funkcja istnieje, co wzywa co w repozytoriach. Nie jest wymagany grep.

    Spróbuj CodebaseChat