Saker ni stör er på i andras kod?

Tyckte det kunde vara skoj med en sån här tråd. Vilka är era pet peeves?

En grej jag ogillar är extremt långa rader, typ 250+ tecken i värsta fall. Gör att man antingen tvingas scrolla horisontellt eller får en kodgröt om man slår på line wrapping. Gör det dessutom svårt att se vad som ändrats inom raden när man kollar diffar.

När utvecklaren förutsätter att de som läser koden är telepatisk (kan läsa utvecklarens tankar och intentioner) och därför anser att kommentarer är slöseri med tid.

Håller med om att långa rader är riktigt segt. Hur gör du själv när du börjar få långa rader? Själv brukar jag antingen skita i det eller försöka intendera det vid exempelvis logiska operatorer.

Jag stör mig på överkomplicerad kod, onödigt långa namn på variabler eller för mycket whitespace. En jag pluggade med skrev onödigt komplex kod för att lösa enkla uppgifter. Nästan alla jag sett som inte är vana vid att programmera slänger in fyra-fem rader whitespace när jag hade haft en. Nackdelen med mycket whitespace är ju så klart att man får mindre plats för kod på skärmen.

I bästa fall är kommentarer bara överflödiga, i värsta fall är de vilseledande (för att någon missat att uppdatera dem när de ändrat koden). Kan man inte skriva kod som går att läsa så är det hög tid att lära sig.

Försöker radbryta det på logiska ställen, t.ex. mellan argument eller deluttryck. Brukar köra en indent på 2 för fortsättningsraderna jämfört med 4 för block. En fördel med en fix indent är att man inte får en massa otydliga diffar för att grejer måste alignas om.

Tycker det känns mer okej med långa rader om strukturen är uppenbar och inte behöver ändras (typ långa rader i någon fix tabell), men är det krångligare grejer så minskar det läsbarheten som fasen för mig iaf.

Självdokumenterande kod är en myt för mig. Behövs mer än bara ritningarna till maskinen. Man vill även veta vad komponenterna ska göra, och vilka antaganden som gjorts.

Personligen anser jag det viktiga är att skriva effektiv kod. läsbarheten får komma i andra hand.

Samma här, men jag radbryter vid sista mellanslaget innan kolumn 72. Orkar inte tänka på var det är logiskt att bryta raden, då tappar jag fokus på vad jag höll på med.

Gör så ibland också. Lite samma grej med #includes, där jag alltid försökte gruppera headers logiskt tidigare. Nu för tiden brukar jag köra bokstavsordning. Blir bara en inkonsekvent röra till slut ändå om man anstränger sig.

Om koden inte är självdokumenterande anser jag att utvecklaren har misslyckats. Bra namn på variabler och funktioner räcker gott och väl för att en annan ska förstå vad som händer.

Jag är också av åsikten att kommentarer i regel är av ondo. Dels för att jag upplever att många kommentarer är redundanta, dels för att de sällan underhålls. När någon refaktoriserar eller utvidgar en funktion som någon annan har skrivit, är det lätt hänt att kommentarerna är oförändrade. Detta kan lätt bli vilseledande i det långa loppet. (Tro mig, när man har suttit i ett system med en kodbas uppemot 2 miljoner rader kod, är detta inte allt för ovanligt förekommande...)

Med det sagt är så klart inte kommentarer alltid onödigt. Har man en funktion som räknar ut något kan det vara intressant att referera till var någonstans man har tagit formeln ifrån. Detta underlättar för andra om det uppstår en bugg och andra utvecklare ska försöka ta tag i det.

Namnge variabler, konstanter och funktioner ordentligt så slipper du skriva en massa kommentarer som ingen kommer att underhålla ändå.


Det går utmärkt att göra båda, detta är bara en dålig ursäkt från programmerare som är lata.

Jag kan bara instämma på detta. Många programmerare är tyvärr nöjda när de har löst problemet, och går snabbt vidare till nästa punkt i backloggen. De tänker inte på att koden ska vara lätt att underhålla - att det faktiskt finns ett värde i att spendera en timma extra med att refaktorisera den - utan skjuter på det problemet till någon annan. Det skapar i det långa loppet onödig komplexitet och är ytterst kontraproduktivt då man bygger på sig en s. k. teknisk skuld.