Håller du med om dessa 7 kodtips?

1. Avoid abbreviating variables (pw => password)
Ja

2. Limit function arguments (aim for 3)
Ja

3. Simplify conditional expressions
Ja

4. Declare variables close to their usage
Nej, beror ju på vilken typ av variabler och vad dom menar med close men inget jag tycker är speciellt viktigt.

5. Avoid unintended consequences in functions
Ja, jag brukar inte medvetet lägga till buggar

6. Functions should do one thing (avoid long functions)
Ja, inom rimliga gränser. Men bra för nybörjare att tänka på detta.
Det viktigaste är att koden är lätt att läsa och förstå.

7. Stop writing zombie code
Ja, versionshanterare är guld värd när man ska rensa gammal kod.

Jag tycker listan var vettig! Sen som någon sa, en genomtänkt felhanteringsstrategi är bra - ofta har man ju minst 2 kategorier "fel". Den ena kanske är "ok" o kan fångas och kompenseras för direkt i funktionen, den andra ska eskaleras vidare.

Annars gillar jag KISS metoden, dvs "keep it simple stupid". Håll koden enkel o tydlig, använd inte onödigt komplexa mönster o lösningar där det inte krävs. Abstrahera på en lagom nivå.

Var konsekvent gällande namnsättning och "pattern" som används.

Var öppen för att förändra ditt mönster när du byter paradigm, t.ex. från MVC -> Blazor Server -> Blazor Webbassembly, varje teknisk lösning har ett mönster som den är gjord för och som ger minst motstånd.

mvh Lazze

Framförallt så blir de deklarerade i det Scope där de används och nås inte utanför relevanta metoder. (Beroende på språk då givetvis)

function1(){
//Stuff 1
}
function2(){
//Stuff 2
}
function3(){
//Stuff 3
}

function1();
function2();
function3();

//Stuff 1
//Stuff 2
//Stuff 3

Det blir svårare att återanvända funktioner som gör många saker. Det är mer en fråga om att en funktion ska ha "only one reason to change", d.v.s. ett ansvarsområde.

Bra lista generellt, men viktigaste som inte är med är felhantering och möjligheten att koden som använder funktionen se när ett fel har skett och hantera det. Ofta kallar man på olika APIer med mer eller mindre skumma fel som händer ibland, då gäller det att hantera felet på ett vettigt sätt där det uppstår så det är lätt att felsöka och fixa när de senare uppstår. Inbakat med detta brukar det kunna hjälpa att ha bra system för att logga vad som händer, då framförallt när det går fel såklart

function1(){
//Stuff 1
}
function2(){
//Stuff 2
}
function3(){
//Stuff 3
}

function1();
function2();
function3();

//Stuff 1
//Stuff 2
//Stuff 3

På jobbet hittade jag en metod som var 400 rader lång, fick sitta och scrolla flera steg för att försöka begripa vad den gör. Där hade en uppdelning med tydliga funktionsnamn varit mycket mer lättläsligt.

I vårt huvudprojekt på jobbet har jag svårt att hitta funktioner med färre än 400 rader :/

Det är nog ganska vanligt, framförallt med kod som bara körs på ett ställe och är del av någon form av huvudlogik

För legacy kod är det vanligt, givetvis noll tester också. För vem kan testa en metod på 400 rader 😜
Personligen tycker jag det är vidrigt, vill inte behöva scrolla i metoden för att följa hela flödet. Koden för en funktion ska få plats på skärmen, max 60 rader.

Jag har som riktlinje runt max 200 rader i en klass, annars börjar klassen bli för komplex och förmodligen göra mer än tänkt.

I vårt fall handlar det om ett butikssystem/kassaprogram som är skrivet i VB6. Det finns klasser med över 30.000 rader kod. Hela projektet består av över en miljon rader kod. Mycket är förstås copy-pasta-kod.

Men att vissa funktioner är på flera hundra rader är inte så konstigt. Exempelvis komplexa utskriftsfunktioner som ska skriva ut rapporter av olika slag. Vet inte hur dessa funktioner skulle kunna göras mindre.

Tack och lov utvecklar jag funktioner i C# som jag exponerar mot VB6-projektet via COM, så jag behöver inte peta så mycket i VB6-kodbasen

På tal om att scrolla (med mushjulet), så är det inte möjligt i Visual Studio 6 som standard, men tack och lov finns det ett tillägg som gör det möjligt. Inte för att min chef installerat det, men så sitter han kvar i Windows XP också

Och tester... Tror inte det fanns några testprogram á la xUnit etc. på VB6-tiden, så några tester existerar absolut inte.

Fånga exceptions och göra dem förståeliga, men också att ha vettiga else satser som loggar eller i alla fall gör något ifall udda fall (även de som inte borde gå) uppstår. Vet inte hur många gånger jsg läst i loggar något i stil med ’wtf - impossible case parameter ’x’ is null after validation’ och liknande rader som exekverats...

Jo, men det finns ju en sweet spot där -- och många verkar propagera för att sweetspoten är typ 5-10 rader per funktion.
I mina ögon så är det bättre med en funktion på 50 rader än 5 st på 10 om och bara om den koden inte ska eller kan användas på andra ställen också. Är det något återanvändbart så ska det förstås vara i en funktion och inte repeteras.
Men att skapa dussintals minifunktioner som enbart används i exakt samma ordning ser jag oftare som något negativt än något positivt.

1. Avoid abbreviating variables (pw => password)
Ja, jag föredrar att undvika förkortningar. Det ökar läsbarhet och med en modern IDE får man ändå autocomplete.

2. Limit function arguments (aim for 3)
Inte något jag jag direkt reflekterar över när jag skriver kod.

3. Simplify conditional expressions
Ja, varför skulle man inte göra det om man kan det?

4. Declare variables close to their usage
Ja.

5. Avoid unintended consequences in functions
ja, återigen - varför skulle man göra annorlunda? edit: antagligen jag som inte fattar vad som menas här.

6. Functions should do one thing (avoid long functions)
Ja. den här är vettig och en vanlig junior synd. Bryt ut och håll funktioner små.

7. Stop writing zombie code
pass, vet inte vad zombie kod är men det låter dåligt.

Möjligen menas att funktioner inte ska ha sidoeffekter som förvånar den som applicerar/anropar funktionen. Till exempel är det ju lätt att lista ut att

async function getDataFromServer(): Promise<Data>

kommer göra en förfrågan till en server eller att

function logWarning(message: string): void

kommer skriva någon form av output, men jag skulle inte förvänta mig att

function isEligible(user: User): boolean

har några sidoeffekter alls (utom möjligen eventuell loggning, beroende på sammanhang).

Tack för förtydligandet. Skulle aldrig sätta mitt godkännande på en PR som checkar in kommenterad kod, annat än kanske i något väldigt specifikt undantagsfall. Borde vara tvång på att använda git add -p, kan jag känna ibland …

async function getDataFromServer(): Promise<Data>

function logWarning(message: string): void

function isEligible(user: User): boolean

Ja precis, unintended sideffects är ju till exempel om ’isEligible’ skulle göra synkrona anrop mot en server eller skriva data till en databas, eller ändra status på något eller sånt...

Då borde den heta typ ’refreshEligibleState’ eller något istället