Samenvatting

Deze gratis ai code review tool is een op regels gebaseerde pre-review checker. Plak een git diff of een codefragment en hij scant de toegevoegde regels op dertien patronen: hardgecodeerde geheimen, met strings opgebouwde SQL, ingeslikte uitzonderingen, uitgeschakelde tests en debugresten. Hij markeert ook te grote wijzigingen en ontbrekende tests en geeft daarna een score van 0 tot 100 met bevindingen per regelnummer. Alles draait in je browser, er wordt geen AI-model gebruikt, en het doel is de mechanische problemen op te ruimen voordat een mens reviewt.

Controleer je diff voordat een reviewer dat doet

Plak een git diff of een snippet. Deze gratis ai code review tool zoekt in je browser naar geheimen, onveilige SQL, ingeslikte fouten, achtergebleven debugcode en te grote wijzigingen, en geeft de pull request een score op 100.

Controleer mijn diff
Ingenieur bekijkt een side-by-side codevergelijking op een monitor

Pre-review diffcontrole

Plak een unified diff of willekeurige code. Alleen toegevoegde regels worden gecontroleerd als er een diff wordt herkend. Wat je plakt, verlaat je browser niet.

--/100
Plak code om te starten
Nog niets gecontroleerd.
    Hoe het werkt

    Waar de checker naar kijkt, en wat hij negeert

    Alleen toegevoegde regels

    Als je een unified diff plakt, leest de checker de hunk-headers, telt hij de regelnummers in het nieuwe bestand en scant hij alleen de regels die je hebt toegevoegd. Verwijderde regels en ongewijzigde context leveren nooit een bevinding op, dus je wordt niet afgerekend op oude code.

    Score op basis van ernst

    Er zijn dertien regels in drie niveaus. Hoog kost 15 punten: hardgecodeerde geheimen, eval, met strings opgebouwde SQL, uitgeschakelde TLS-controles. Middel kost 7: ingeslikte uitzonderingen, gefocuste tests, innerHTML en een diff van 400 regels. Laag kost 2: TODO's, debugprints en uitgecommentarieerde code. Elke regel telt maximaal drie keer mee.

    Controles op omvang en tests

    Boven de 200 toegevoegde regels krijg je een duwtje om de wijziging te splitsen, boven de 400 een steviger duwtje. Dat volgt de SmartBear-studie bij Cisco, die laat zien dat de kwaliteit van een review zakt zodra een reviewer meer dan 200 tot 400 regels tegelijk moet bekijken. Een diff met meer dan 50 toegevoegde regels zonder testbestand wordt ook gemarkeerd.

    Gebruik

    Van plakken naar een schone pull request in vier stappen

    1. 1

      Plak je diff

      Draai git diff main...HEAD, of git diff --staged voordat je commit, en plak de uitvoer. Een gewoon codefragment werkt ook, maar dan verlies je bestandsnamen en de detectie van testbestanden.

    2. 2

      Lees eerst de hoge bevindingen

      Rode items zijn de punten waar een reviewer blijft haken. Een hardgecodeerde sleutel in een commit blijft in de geschiedenis staan, ook nadat je de regel hebt verwijderd. Roteer hem dus, verwijder hem niet alleen.

    3. 3

      Los de rest op of onderbouw ze

      Elke bevinding komt met een fix van een regel. Is een melding een false positive, zet dat dan in de PR-beschrijving. Dan hoeft de reviewer die vraag niet zelf te stellen.

    4. 4

      Kopieer de checklist

      Met de kopieerknop zet je de bevindingen om in een markdown-checklist die je in de PR-tekst kunt plakken, zodat de reviewer ziet wat je al hebt gevonden.

    Waarom een pre-check

    De eerste dertig seconden van een review hoeven niet naar console.log te gaan

    Je kent de routine als een collega een pull request opent. Je scrolt door de diff en ziet een achtergebleven debugprint, een TODO zonder ticket, een overgeslagen test en een catch-blok dat de fout inslikt. Daar is geen mens voor nodig. Je hebt een checklist nodig die draait voordat het verzoek de deur uitgaat. Daar vult deze tool het gat. De aandacht van een reviewer is beperkt: uit de SmartBear-studie bij Cisco-reviews blijkt dat de foutdetectie standhoudt wanneer mensen 200 tot 400 regels in 60 tot 90 minuten reviewen, en daarboven afneemt. Elke minuut die naar mechanische bevindingen gaat, is een minuut minder voor de vragen die alleen een mens kan beantwoorden: is dit de juiste aanpak, past het bij de architectuur, en klopt het over zes maanden nog? De tool vervangt geen reviewer en doet ook niet alsof. Hij haalt de goedkope bezwaren weg, zodat de menselijke review begint bij het interessante deel.

    • Vangt de mechanische bevindingen op voordat het reviewverzoek de deur uitgaat
    • Geeft elke bevinding een regelnummer uit de hunk-headers van de diff
    • Draait lokaal, dus het is veilig om bedrijfscode te plakken
    Twee ingenieurs bespreken een codewijziging bij een laptop
    FAQ

    Vragen over de checker

    Is dit een AI code reviewer of een linter?
    Strikt genomen geen van beide. Het is een op regels gebaseerde pre-review checker. Er leest geen model je code en er wordt niets gegenereerd. Dertien patroonregels scannen de toegevoegde regels op de dingen die een reviewer in de eerste dertig seconden opmerkt: geheimen, onveilige met strings opgebouwde SQL, ingeslikte uitzonderingen en achtergebleven debuguitvoer. We noemen het eerlijk zo, want een AI code reviewer die gokt is slechter dan een checklist die dat niet doet.
    Verlaat mijn code mijn browser?
    Nee. De controles draaien in JavaScript op deze pagina. Er is geen upload, geen API-aanroep en geen account. Het enige dat wordt vastgelegd is een anoniem event dat de tool is gebruikt, zonder inhoud uit het tekstvak.
    Waar komen de regels van 200 tot 400 regels en het testbestand vandaan?
    De grens voor de omvang volgt de SmartBear-studie over reviewdata van Cisco, die aanbeveelt om niet meer dan 200 tot 400 regels tegelijk te reviewen. De regel voor kleine wijzigingen volgt de openbare engineeringpraktijken van Google voor kleine CL's. De regel over ontbrekende tests is onze eigen conventie: een diff met meer dan 50 toegevoegde regels zonder testbestand krijgt een melding, omdat reviewers die vraag toch altijd stellen.
    Hoe wordt de score berekend?
    De score begint op 100. Elke bevinding trekt punten af op basis van de ernst: 15 voor hoog, 7 voor middel en 2 voor laag. Elke regel telt maximaal drie keer mee, zodat één luidruchtige regel de score niet op nul kan zetten. Het is een conventie om werk te ordenen, geen maatstaf voor codekwaliteit. Een score van 100 betekent dat geen enkele regel is aangeslagen, niet dat de code klopt.
    Wat mist hij?
    Alles wat begrip vraagt: verkeerde bedrijfslogica, race conditions, een slechte abstractie of een API die slecht zal verouderen. Regex-regels geven ook false positives, bijvoorbeeld een testfixture met een nep-wachtwoord. Behandel elke bevinding als een vraag die je moet beantwoorden, niet als een oordeel.
    Met welke talen werkt hij?
    De regels zijn tekstpatronen, dus ze werken op JavaScript, TypeScript, Python, Java, Go en de meeste C-achtige code. Sommige regels zijn taalspecifiek: bare except hoort bij Python, System.out.println bij Java en InsecureSkipVerify bij Go. Plak een unified git diff en de regelnummers komen uit de hunk-headers.
    Is hij gratis?
    Ja, zonder aanmelding. Wil je tijdens je review antwoorden over de rest van je repository, zoals wie deze functie aanroept of waar een configwaarde wordt gelezen, daarvoor is codebasechat.

    Review met de hele repo in beeld

    Een diff laat zien wat er is veranderd, niet wat het raakt. codebasechat beantwoordt vragen over je codebase in gewone taal, zodat je kunt nagaan wie de gewijzigde functie aanroept voordat je goedkeurt.

    Probeer codebasechat gratis