Vad är för dig Nybörjarkod vs Proffskod?

Inget enkelt ämne det här, men för mig är det uppenbara att snygg/bra kod är kod som är lätt att läsa, förstå och underhålla. Att tävla om vem som kan få in samma logik på minst antal rader har ingen merit på en arbetsplats enligt mig.

Enkla tumregler är:
* Tydliga namn på allt
* Kommentarer där det behövs
* Bryt ned problemet i mindre delar. "Söndra och härska".
* Inte återupprepa kod. Bryt ut i stödfunktioner isf.
* Korrekt indentering och lagom med tomma rader.

Gällande "Guard Clauses" så håller jag inte med videon. Att behöva skriva denna "boilerplate" för varenda funktion där det enda det gör är att dölja att du anropat funktionen felaktigt ser jag ingen vinning med. Jag håller vid konceptet "fail fast, fail hard". Att få ett felmeddelande när man anropar funktionen är 1000ggr bättre än att den bara returnerar något standardvärde.

Sedan så är det konstigt att bara vakta mot null, men inte mot felaktiga typer. Om du förväntar dig en array, men får en sträng? Bägge har .length.

Jobbar som testledare så småler när jag ser att en definition mellan noob och pro skulle vara buggfri kod

Enligt mig är proffskod sådan kod som vem som helst lätt kan sätta sig in i och arbeta vidare på i framtiden. Arbeta på annans kod är vardag för utvecklare, men sällan ett moment i utbildningar. Ser ofta brister här.

Ett annat kriterie är robust kod. Dvs, om jag pillar på A så ska inte B bryta ihop.

@AplAy:
Proffskod,
Uppdelat i små delar med tydliga namn där man kan läsa koden som en bok och förstå vad den gör. Varje metod gör en sak.
Återanvänder kod (inte copy/pasta), utan återanvänder genom att skapa generics eller arv.
Skriver kod som inte är hårt kopplade mellan beroenden, så om man behöver byta ut delar är det enkelt att göra det utan att hela applikationen går sönder. Skriver kod som är enkelt att testa, samt även tester som verifierar att koden de skrivit fungerar.

Nybörjarkod,
Skriver oftast mer kod än som behövs för ändamålet. Tenderar att slarva med variabel- och metodnamn.
Skriver hårt kopplade beroenden mellan komponenter, vilket i sin tur snabbt kan bli spaghetti och huvudvärk.
I och med hårda beroenden är den också väldigt svår att skriva tester till, vilket gör att nybörjare knappt skriver tester. Skriver klasser eller metoder som är flera hundra rader, istället för att bryta upp det i olika där varje klass har ett jobb.

Jag håller helt med. Att nullchecka inne i varje metod kan dölja ett eventuellt problem. Jag föredrar att throwa ett exception, dekorera metoden med dokumentation att X exception kan throwas om Y har detta värde. Så får personen som använder metoden hantera felet.
Däremot om du anropar något API och eventuellt kan förvänta dig null, t.ex. om du ska hämta en order och den inte finns. Då tycker jag det är okej att metoden returerar null istället för att throwa exception. Exceptions är kostsamma och ska inte missbrukas där det inte behövs. En duktig programmerare vet per automatik när det ena eller det andra ska användas. Detta är något man lär sig med erfarenhet och att jobba med seniora utvecklare.

För mig är proffskod sådan som även har väldefinierade unit och component tests.

många som tycker sig vara pro-seniora lider av abstraktions-sjukan. Dvs de abstraherar och intterface:ar i så många nivåer att när en annan utvecklare ska ta över, så hittar den knappt den kod som faktiskt körs. Pro för mig är

1. Förvaltningsbart
2. Dokumenterat
3. Rätt nivå, dvs en enklare webbsida eller enklare rutin, behöver inte kompliceras med alla verktyg i lådan
4. Hellre några rader fler som visar tydligt vad som sker än "c00la konstrukts"

Förutom de tekniska skillsen, så är ju humana skills viktiga, så som

1. Humor
2. Kunna jobba i team och kommunicera
3. Våga be om hjälp
4. Tydliga kommunicera om man inte är klar till utsatt tid
5. Kunna prata med kund/beställare och kunna hålla bra demo för det man byggt
6. Våga ta ansvar för en hel funktion/flöde, inte bara den kodsnutt som man själv skapat

mvh Lazze

De programvaror jag pillat i på jobbet har mer varit "kan du fixa detta helst igår till ingen kostnad alls" så blir resultatet ofta därefter. Snabbfixar med absolut minsta tanke bakom.

På fritiden kan man lägga hur mycket tid som helst på något man vill göra "snyggt". Nu är inte min huvuduppgift på jobbet programmering så de brukar acceptera något halvdant som löser problemet för stunden.

Det finns otroligt mycket att säga på ämnet, men jag vill ta upp en bra princip till, nämligen att skriva vad man menar™.

Den här PR:en som jag skrev i veckan illustrerar denna princip rätt bra. Jag förenklade

function cliJoin(...args) {
    let command = '';
    for (let i = 0; i < args.length; ++i) {
        let arg = args[i];
        if (arg.length > 0) {
            command += command === '' ? arg : ' ' + arg;
        }
    }
    return command;
}

till

function cliJoin(...args) {
    return args.filter(x => x.length > 0).join(' ');
}

För mig är det uppenbart att det som menas™ är

Returnera alla icke-tomma element joinade med mellanslag.

mycket mer än

Låt command vara den tomma strängen; för alla i mellan 0 och listans längd, låt arg vara elementet på index i; om det är icke-tomt, appenda arg på command om command är den tomma strängen, annars arg med ett mellanslag framför …

och oftast bör det som menas™ också vara det som står. Undantag finns och bör, anser jag, dokumenteras med kommentarer – det är precis sådant vi ska ha dem till, inte till att förklara att let i = 0; // skapar variabeln i och sätter den till 0 och liknande.

Proffskod är när man använt enklast möjliga lösning för att uppnå det man vill. Nybörjarkod är när man krånglat till det hela i onödan, använt onödigt komplicerade lösningar för att visa att man kan, eller hittat på en egen lösning på ett standardproblem för att det är häftigt.

Jag håller med om massor som skrivits här, men jag tycker nästan, att efter 25 år, det viktigaste av allt är att kod skall vara lättläst och förutsägbar. Allt annat är små myror jämfört med det.

Lättläst och förutsägbar kod är skriven för någon annan att läsa och använda - om så "någon annan" är en själv, 12 månader senare.

Allt det andra som pratats om här är fint det med, men jag tycker det är en 10 mot 1 ratio på viktigheten.

@Alling: Jag har sett dina poster här i forumet i några år nu och på dina svar kan man se hur du gått från "noob" till att närma dig "pro" - Skitkul tycker jag! Vi känner ju inte varandra alls, men jag gillar ändå när man ser hur du hela tiden har förbättrats och kommit med än mer insiktsfulla kommentarer och tips!

Bra amatörkod: finns inga uppenbara buggar
Proffskod: är uppenbart att inga buggar finns

Lite mer seriöst: proffs fattar att kod läses långt oftare än man skriver det. D.v.s. de mest kompakta är sällan det bästa, simplaste sättet att lösa problemet är typiskt det bästa sättet.

Förvaltningsbart kan innebära många saker, några exempel:

1. Inte använda för många externa referenser / 3e parts bibliotek. Då dessa kan gå ur tiden, vara osäkra
2. Efterlämna en utvecklingsmiljö där projektet fungerar att kompilera, till exempel en virtuell maskin. Om möjligt så ska det finnas tester att köra för att verifiera projektet. manuella eller automatiska, inte bara unit-tester
3. Se till att alla konton / ip adresser / lösenord finns dokumenterade
4. Datamodellen ska finnas återskapningsbar om en databas används i någon form
5. Källkoden ska vara versionshanterad i ett repo
6. Dokumentation ska ha ett avsnitt för "kommande utvecklare", där man beskriver hur man kommer igång, o upplägget av projektet så att arkitekturen kan hållas över tid

Några saker för förvaltningsbarhet IMHO

o en sista sak, koden är bara en liten del av hela leveransen som kund förväntar sig

// Lazze

Jag tycker det är väldigt skevt att försöka låsa in sina utvecklare i ett fåtal verktyg. Alla har olika preferenser, och verktyg kommer och går. Lägg in era style checks etc i er CI-pipeline, och låt sedan utvecklare uppfylla dem hur de vill. Lintern ni använder är med stor sannolikhet inte bunden till VS, och är den det borde ni byta linter.

Ps. Jag är givetvis medveten om att det inte är du som sätter dessa krav, så "ni" riktar sig till din arbetsplats, och inte dig som person.