Kodgranskningar fastnar av den dummaste anledningen: stil. En person vill ha “snyggt”, en annan vill ha “konsekvent”, och plötsligt blir en enkel ändring en tråd som ingen tycker är kul. Under tiden fortsätter kodbasen att glida isär, och nya teammedlemmar blir straffade för att de inte kan läsa allas tankar.
Den här kodstilsgranskningen är byggd för tekniska ledare som behöver att granskningar går snabbare utan att sänka standarden, seniora utvecklare som vill coacha stil utan att låta petiga, och plattform- eller DX-ingenjörer som försöker linjera flera repo:n mot en gemensam konvention. Resultatet är en pedagogisk granskning med radnivå-noteringar, den referensstandard som används (som PEP 8, Google Java Style eller en accepterad community-guide) och konkreta åtgärder som teamet kan applicera snabbt.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: pedagogisk kodstilsgranskning
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[VERSALER_MED_UNDERSCORE] |
Ange ett variabelnamn eller en identifierare med stora bokstäver, där orden separeras med understreck. Formatet används ofta för konstanter eller platshållarvärden. Till exempel: "MAX_CONNECTIONS eller DEFAULT_TIMEOUT"
|
|
[PREFERENS_FOR_STILGUIDE] |
Ange vilken stilguide som ska användas för granskningen. Använd "DEFAULT" för att tillämpa den mest allmänt accepterade community-guiden, eller ange en specifik guide som är relevant för programmeringsspråket. Till exempel: "DEFAULT eller Google Java Style Guide"
|
|
[PROGRAMMERINGSSPRAK] |
Ange programmeringsspråket för kodsnutten som analyseras. Det avgör vilken stilguide och vilka konventioner som tillämpas. Till exempel: "Python, JavaScript eller Java"
|
|
[TEAMSTORLEK] |
Ange hur många utvecklare som arbetar med kodbasen. Det hjälper till att anpassa rekommendationer efter samarbetsbehov och vanliga utmaningar i arbetsflödet. Till exempel: "5 utvecklare"
|
|
[KODBASENS_STORLEK_LOC] |
Ange kodbasens ungefärliga storlek i antal kodrader (LOC). Det hjälper till att bedöma komplexiteten och omfattningen av stilgranskningen. Till exempel: "50 000 LOC"
|
|
[KODEXEMPEL] |
Klistra in kodsnutten som ska analyseras. Se till att den speglar de problem eller konventioner du vill få granskade och att den innehåller tillräckligt med kontext för att ge meningsfull återkoppling. Till exempel: "def my_function():
print('Hello, world!')"
|
Proffstips för bättre resultat från AI-prompten
- Klistra in en “granskningslagom” snutt, inte ett helt repo. Begränsa koden till den funktion/modul som diskuteras (ofta 50–200 rader). Om du dumpar en enorm fil tenderar granskningen att bli generiska råd i stället för exakta radnoteringar.
- Säg språk och runtime-antaganden uttryckligen. Även om koden “ser ut som JavaScript”, skriv “TypeScript (Node 18)” eller “Python 3.11” så att prompten kan välja rätt community-standard och undvika irrelevanta regler. En bra uppföljning: “Anta att detta körs i en strikt lintad monorepo; notera stilproblem som ofta skapar fel i verktyg.”
- Ange en verklig stilguidepreferens när teamet redan har en. Om er organisation följer en standard som “Google Java Style” eller “Black + isort defaults”, ange den så att granskningen inte blandar konventioner. Du kan också be om: “Tillämpa våra befintliga konventioner: 2 mellanslags indrag, avslutande kommatecken där det är giltigt, enkla citattecken och inga semikolon.”
- Iterera med riktad skärpning, inte “gör om”. Efter första resultatet kan du fråga: “Prioritera nu om fynden efter risk för merge-konflikter och ge mig bara de 7 viktigaste ändringarna att begära i denna PR.” Det gör granskningen användbar i ett verkligt reviewflöde.
- Be om en patch-liknande omskrivning när du vill ha åtgärd, inte bara kommentarer. Grundprompten är pedagogisk, så den förklarar. Om du behöver en snabb fix, följ upp med: “Skriv om snutten genom att tillämpa dessa stilfixar men behåll beteendet identiskt, och visa bara den uppdaterade koden.” Ärligt talat är det snabbaste sättet att avblockera en PR utan cykelställsdebatt.
Vanliga frågor
Engineering managers använder den för att deeskalera debatter i granskningar och sätta en konsekvent standard utan att behöva vara “stil-domare” varje vecka. Tech leads använder den för att coacha utvecklare med tydlig vägledning på radnivå som håller PR:er i rörelse. Seniora mjukvaruingenjörer använder den när de vill handleda vänligt men ändå vara precisa kring konventioner. Developer experience (DX)- eller plattformsingenjörer använder resultatet för att informera linting- och formatteringsstandarder som team faktiskt accepterar.
SaaS-produktteam får värde eftersom de levererar kontinuerligt, och små stilinkonsekvenser ackumuleras till långsammare granskningar och riskablare hotfixar. Den pedagogiska tonen hjälper också när flera squads rör samma kärntjänster. Byråer och utvecklingshus använder den för att normalisera kvalitet mellan kundprojekt där varje repo har olika historik och bidragsgivare. Fintech och reglerade verksamheter gynnas när granskningar måste vara objektiva och spårbara, eftersom subjektiva reviewkommentarer kan skapa friktion och fördröja releaser. Open source-maintainers använder den för att minska churn bland contributors genom att förvandla “snälla, formatera om” till tydlig, vänlig vägledning som nybörjare kan följa.
En typisk prompt som “Granska min kod och säg vad jag ska fixa” misslyckas eftersom den: saknar en explicit referensstandard, så råden blir en blandpåse av preferenser. Den ger ingen föranalys eller antaganden, vilket gör att regler tillämpas inkonsekvent. Den ignorerar radnivå-detaljer, så du får vaga noteringar som är svåra att omsätta i en PR. Den glider ofta över till arkitektur, prestanda eller åsikter om “bästa ramverk” i stället för att hålla sig inom scope. Och den fastnar i petitesser i stället för att fokusera på konventioner som minskar merge-konflikter och snabbar upp samarbetet.
Ja. Den tydligaste spaken är din stilstandard: sätt [STYLE_GUIDE_PREFERENCE] till en känd guide i stället för DEFAULT, och ange [PROGRAMMING_LANGUAGE] så att granskningen väljer rätt referens när du vill ha DEFAULT-beteende. Du kan också lägga till kontext om snuttens omfattning (till exempel “en enskild funktion i en PR” vs “utility-modul som används överallt”) så att granskningen kan prioritera konsistensproblem med hög påverkan. En användbar uppföljning är: “Tillämpa den valda stilguiden, men tillåt undantag för läsbarhet när de minskar kognitiv belastning; förklara varje undantag kort.” Det håller resultatet pragmatiskt, inte rigidt.
Det största misstaget är att låta [PROGRAMMING_LANGUAGE] vara underförstått — i stället för “här är min kod”, säg “Python (PEP 8)-snutt från en Django-view” så att reglerna inte gissas. Ett annat vanligt fel är att hålla [STYLE_GUIDE_PREFERENCE] vag; “använd best practices” är svagt, medan “DEFAULT (använd den vanligaste community-guiden)” eller “Google Java Style” är genomförbart. Folk klistrar också in kod utan radbrytningar eller med trasig indragning, vilket gör noteringar på radnivå opålitliga; klistra alltid in formaterad kod så som den ser ut i repo:t. Till sist förväntar sig team ibland arkitekturfeedback trots att den här prompten är avgränsad till stil; om du vill ha designkritik bör du köra en separat review-prompt.
Den här prompten är inte idealisk för att diagnostisera buggar, hitta säkerhetsproblem eller utvärdera prestandaflaskhalsar, eftersom den medvetet håller sig till stil och inget annat. Den passar heller inte om ditt team vägrar en gemensam standard och ser formatering som personligt uttryck, eftersom hela poängen är samsyn. Och om din snutt är extremt ofullständig (saknad kontext, trasig syntax, halva rader) blir granskningen på radnivå mindre pålitlig. I de fallen: kör en formatterare eller linter först och kom tillbaka med ett korrekt formaterat utdrag.
Konsekvent stil handlar inte om perfektion; det handlar om att göra ändringar lätta att läsa, granska och underhålla. Klistra in din snutt i promptvisaren och låt granskningen ge dig lugna, rad-för-rad-åtgärder som teamet kan enas om.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.