Vanligt att störa sig på kollegors kod?

Förvånansvärt sällan jag stör mig på mina kollegors kod, vi har en satt kodstandard och de flesta är bra på att följa den.
Oftast är det min egna kod (kanske delar upp en funktion/metod konstigt i farten) och det går ju alltid att åtgärda om man kommer på det i rimlig tid.

Bristfällig kod ser jag som ett utmärkt tillfälle att skapa en diskussion, och förhoppninsvis lär vi oss båda något.

Det enda jag faktiskt stör mig på, det är när folk envisas med att sär skriva allt.
t.ex:

private static String SWE_CLOCKERS;

Tvärtom för mig, har lättare att förstå och redigera/rätta andra personers kod. Men att sitta med en blank sida och skriva någon funktion? Blank i huvudet omedelbart.

För att uttrycka mig lindrigt så har jag full förståelse för hur Linus Torvalds uttryckt sig ibland.
Låt koden tala men ibland säger den mest skit.
Något mer som är störande är projekt där utvecklare skriver kommentarer på annat språk än engelska.
Jag kan störa mig på allt även egen kod samtidigt som jag ibland inte bryr mig alls.

Tror folk här i tråden borde testa mindfullnes-övningar, eller på andra relevanta sätt söka komma i balans med sig själva. Känns inte helt optimalt att man ska behöva hetsa upp sig och bli arg över andras kodande.

Ja, vad gäller att adressera problemet så att det allra minst hålls hanterbart så känns det ju som att just arbeta mer/bättre tillsammans är lösningen.

Parprogrammering, att granska varandras föreslagna kodändringar (gärna med direkt konversation snarare än att bara lämna "arga lappar"), retrospektiv, osv är bra verktyg.

Nu kodar jag inte så mycket längre, men även om kod kan vara felskriven på en lång rad olika sätt, och ändå funka, retar jag mig fortfarande på bristen av dokumentation inne i koden. Nyligen har det slagits upp som ett av de största problemen inom programutveckling.

Nu är det länge sen, men skrev ett antal spel med riktig spagettikod, visst, dom funkade men en professionell kodare hade slitit sitt hår

stör mig som satan på folk som kör wall of code principen...
går inte hitta ett skit i den utan att först spendera en halv dag och försöka "dekryptera" väggen till något mer läsbart...

eller om man ska snacka mer jobbrelaterat när programmeraren gjort robotprogrammet och bara låtit alla programraderna vara döpta till ABB´s default namn * och kan man inte var varenda kodrad är positionerad i huvet eller mha kordinaterna så ä de en mardröm att jobba med...

Nej, men andra stör sig på min kod.

Jag stör mig på kod vars utvecklare uppenbarligen saknar grundläggande grammatikregler, så som de dem och 'dom'.

Brist på tid är nog det vanligaste problemet. Om man ska göra något halvkomplicerat så har man ofta inte full koll på problemställningen förrän en fungerande version är på plats och då ger det bara marginell nytta att göra om något för att det ska bli snyggare och mer lättunderhållet. Har man en deadline att jobba mot så är det ”good enough” som gäller.

Jag har nog mindre tvångssyndrom än de flesta här eftersom jag sällan stör mig på utseendegrejer som formattering. Och det är sällsynt att jag stör mig på organisation av kod.

Det som däremot gör mig rejält sur är när folk uppenbart inte har gjort ett enda test av sin kod eller övervägt gränsvärdesproblematik och jag blir tvungen att lägga en kväll för att få deras funktionalitet att faktiskt fungera innan demo eller för att komma vidare själv.

Huvudsaken är att man förstår varandra? Ibland (väldigt ofta) skriver man i all hast utan att korrekturläsa.

Ett tips för att få upp kodkvalitet både hemma och på jobbet kan vara att börja använda analysverktyg som t.ex. SonarLint (gratis från https://www.sonarlint.org/) som man via sin utvecklingsmiljö ser problem i filerna man jobbar i. Om man sätter upp en server som analyserar all kod i repon och integrerar det med automatiska byggen kan man få bra koll på status på hela projekt och status på ny kod. Vi får mail från vår server när vi råkar checka in kod som innehåller saker som avviker från regelverket.

Lyckligtvis har jag nästan alltid arbetat i team med extremt duktiga utvecklare, så det har sällan funnits saker att irritera sig på mer än min egen kod. Särskilt när man har varit tvungen att få ihop saker under stor tidspress, men det brukar lösa sig över tid om man refaktoriserar med jämna mellanrum.

Det största irritationsmomentet är annars när systemarkitekter gör onödigt tillkrånglade lösningar för att visa hur duktiga de är på att rita boxar och pilar istället för att hålla det enkelt eller när produktchefen hela tiden försöker forcera in nya obegripliga features från sidan rakt in i våra redan överfulla sprintar. Det kan leda till dålig kod på sikt. Sedan gillar jag inte folk som skriver lika mycket kommentarer som kod. Bra kod dokumenterar till viss del sig själv.

Det håller jag inte med om. Har man bra vanor så skriver man lättläst kod med kommentarer per automatik.
Kommentarer som förklarar kodavsnitt skriver man ibland t.om. före koden som en direkt produkt av att man reder ut vad koden ska göra.

Från ditt inlägg får jag annars det allmänna intrycket av att ditt jobb inte har särskilt bra styrning över utvecklingprocessen.

Vi rejectar inte kod som inte uppfyller kraven, men man får som sagt ett mail. Vissa regler kör vi mer hårda linjen på som t.ex. null-analys, resursläckor och säkerhetshål, men många regler är mer rekommendationer och man kan låta dem vara.
När vi började med detta hade vi redan ett långt gånget projekt så kvaliteten i koden och "kodskulden" var redan i ett skick som inte tillät oss att köra stenhårt på reglerna. Det är dock bra att få en analys gjord på hela kodbasen och få koll på problem i filer som sällan/aldrig någon kikar i.