Fira Programmerarens dag med kodsnack!

void main()
double kakor=""
While {
Kul med en egen dag, det kände inte jag till, ska man äta
function(kakor)
då?
}
kakor{
mums / mums = division by localhost.
}
return.

Hello world!

Är koden dokumenterad eller är det fullt med förkortningar och hårdkodad kod som man måste läsa flera gånger för att förstå?

Det tråkigaste jag tycker är att man inte får koncentrera sig och ens kunskap går upp och ner inom olika områden.
Man kanske en gång gör ett superavancerat program i powershell som har konstig syntax. Folk kan i efterhand tycka, herre jävlar vilket powershell guru. I verkligheten så var man duktig i powershell för 10år sedan när man kodade det, idag så vet man inte ens hur deklarerar man en variabel i powershell utan man får Googla.
Och lite tråkigt blir det när man får ett nytt uppdrag i Powershell, då blir det ska jag lära mig detta på nytt?

Jag har aldrig haft så kul i något annat programmeringsspråk som PHP och jag ljuger aldrig [1]. Kan bero på att jag aldrig har gjort något i PHP professionellt utan bara som hobby. Svårt att sätta ord på vad det är som gör kodning i det språket så underhållande -- lätt att få saker gjort kanske. Jag har inte rört språket sedan 2007 eller något så modern PHP kan mycket väl ha blivit tråkigt.

[1] Medvetet, jag ljuger hela tiden för att jag inte vet bättre och inte orkar kolla upp grejer ordentligt.

Ändå lite humor i ett språk med metodnamn som mysqli_real_escape_string osv 😁
Gillade PHP när jag inte hade testat så mycket annat, nu tycker jag att syntaxen är ganska gräslig och har överlag svårt för dynamiskt typade språk.

Knackat kod i 13 år nu, alltså som arbete. Av någon anledning tröttnar jag aldrig, även om det stundtals är frustrerande as hell. Var dock fruktansvärt längesen jag rörde något i PHP. Satt med det en del innan jag började plugga, men det var mest på hobbynivå 😃

Oj. Hej 2015!

Fortfarande min bästa bit kod jag har skrivit.

Ibland får jag höra argumentet att "kommentarer behövs inte om man skriver bra kod". Jättekul när det är många abstraktionslager, massor med pekare så det är svårt att följa...

Alternativt som för mig, att koden löser komplexa affärsproblem som är helt odokumenterade, och folket på affärssidan har blivit utbytta 72 ggr sen den person som var med från dom när koden producerades....

Nått av det bästa jag hittat var kommentaren "Denna beräkning är en placeholder under utveckling, byt ut den mot korrekt beteede efter samtal med verksamheten" ... efter 11 år. Mao så blev placeholder-beräkningen det som verksamheten såg som "sanning" i 11 år.

Jag firade gårdagen som dom flesta andra dagar, satt och löste en driftstörning som berodde på "någon annans" gamla legacy-fulkod!

Jag hade en rant om Excel i en tidigare tråd, men jag vill nog ändra mig och säga att jag skulle önska bort -all- legacykod. Det är horribelt hur mycket fulkod som producerats på så kort tid, några årtionden på sin höjd.

De nya biblioteken för t.ex. Swish, IDkollen och kryptering har kommentarer, men alla har olika mängd beroende på komplexitet. De flesta metoder skrivs ut i sin helhet, men ibland har det blivit en avstickare. De senaste åren har det lags ned mer tid på att dokumentera IT-miljön och utvecklingsmiljöerna än att lägga till inline-kommentarer på befintlig kod.

Kodstandarder (hur koden ska formateras) har tagits fram för PHP, CSS och JavaScript. Nästa steg är att ta fram dokumentation om hur t.ex. en modell ska se ut och definiera när och hur mycket saker ska dokumenteras.

Men då är det ju inte bra kod.
Iaf inga buggar i kommentarerna eftersom det inte finns några.

Gillar att koda då och då när jag känner för det men gick in i väggen som programmerare, det är ett jävla tryck så det gör jag inte om.

Samma sak här. Började min bana in R&D för småsystem (inbyggda, lite plc osv) och då blev det en hel del kodande (asm, c, java, cpp osv) för att testa hårdvaran man tog fram. Sedan när det började dyka upp mycket färdiga moduler så gick det över till nästan enbart kodande och nu ca 8 år senare kodar jag endast när det är absolut nödvändigt och lejer ut de mer tunga bitarna vid behov.
Intresset för att ta fram nya lösningar har dock inte sinat nämnvärt... bara blivit riktigt gubbgrinig och less på kodandet.

Angående arbetsliv så finns det ordspråket att gräset är grönare på andra sidan. Så jag vet inte vad som är bäst, men att man tror att andra har det bättre.
Jag själv gillar att jobba med emot stora kunder för jag upplever man blir då bättre behandlad av alla andra. Säg att man har strul med ett program, man får knappt någon hjälp alls från supporten.
Om man i samma veva drar ett CC mail till t.ex. Tim Cook (Apples VD) och säger att det berör deras produkter. Ja, man blir helt annat bemöt för exakt samma problem och de kan direkt skicka en tekniker till en.
Samtidigt finns de som argumenterar emot stora kunder med mindre valfrihet.

Det där är en myt, vet ej hur den uppstått, "självdokumenterande" kod existerar inte utan det handlar mer om att programmerare inte lärt sig dokumentera och/eller inte "orkar".

Dokumentation handlar oftast om varför/syfte något görs, personligen tycker jag också det är viktigt att dokumentera variabler, framförallt medlemsvariabler i objekt. Bra med exempelkod i kommenterar med.

Programmerare som praktiserar tekniken DoD (data oriented design) eller 10x kodarna. Med den tekniken kan man ta återanvändning till helt andra nivåer men det blir komplex kod och måste vara noga dokumenterad.

Det är inte frågan, utan om man ska dokumentera dålig faktoriserad kod istället för att fixa den... vilket brukar stämma från rädslan att introducera nya buggar pga dålig kod från början / dåliga tester.

Vad git är till för.

Varför inte både fixa och dokumentera koden

Pratar vi enhetstester brukar de vara ett stort hinder för att fixa kod

Ansvars- och tidskrävande, trist, och oberoendeframkallande.
Teknisk skuld är bra när det är din.

Visst, om det är dåliga kod & tester blir det mer att fixa.

Skrev rekursiv kod i Visual Basic åt en uppdragsgivare men deras programmerarna kunde inte förstå koden, trots att den funkade och löste sin uppgift, så jag fick skriva om rubbet på ett enklare och längre sätt.

För att inte tala om reentrant kod, men det vet numera bara jag och Dave Cutler vad det är.

Vet du?

Var det inte så att deras static code analysis flippade ur och därmed krävde en annan lösning?