Det är att förstå före kodning

Närhelst du siktar på att blogga om en rad olika saker som alla försöker hjälpa människor att skriva kvalitetskod (eller skriva vad som helst) för att förbättra deras arbetsflöde, är du skyldig att få feedback, eller hur?

Missförstå mig inte. Jag välkomnar det. Jag tror att det hjälper till att skapa bättre skrivande i framtiden (det vill säga, jag frågar, vad kan jag göra bättre).

Och med risk för att se ut som om jag "ropar ut någon" (vilket jag inte är), vill jag dela en [unattributed] tweet som jag fick förra veckan:

din titel "högkvalitativ kod" fick mig att sugen på en del hardcore-grejer, men kille ~99% berättelse vs ~1% kod?? faller död på sitt tangentbord

Och jag förstår det. Det finns väldigt lite kod i ett inlägg som syftar till att prata om kod. Men det finns anledningar till detta, och det kommer från några år av både att läsa artiklar, skriva artiklar, läsa kod och skriva kod.

Så jag tänkte att för andra som har samma tankar kan det vara värt att förklara varför jag tar det förhållningssättet jag gör.

Förstå före kodning

För att vara tydlig är ingenting här menat att peka ut någon eller något. Om något är det min generalist i ämnet och varför jag tänker prata om, skriva och dela inlägg om högkvalitativ kod

1 En Oxymoron

Vår nuvarande programmeringskultur verkar främja och vidmakthålla idén om kodning först och [kanske] förståelse senare. Det här verkar bakvänt för mig.

Jag gillar inte kopiera och klistra in kodning eftersom termen är lite av en oxymoron. Du kan inte både skriva kod och kopiera och klistra in den. Det är antingen det ena eller det andra.

Jag tror att Toby nämnde det bäst:

högkvalitativ kod kan inte kopieras och klistras in från internet.

Jag tror att det är viktigt att se till att vi kan skriva koden på egen hand. Och för att göra det måste vi ha lite förståelse.

2 Inbjudan till förståelse

Slutligen kallas det kod av en anledning. I mina ögon är det sista vi behöver oroa oss för själva koden.

Verktyg kan förstås hjälpa, men om du inte förstår felen kan du inte förbättra.

Det vill säga, det är viktigt att förstå vad vi försöker göra och ett högkvalitativt eller robust sätt att göra något på. Därför är det viktigare att förstå koncepten bakom det vi gör än själva koden.

För om du inte förstår konceptet kommer du inte att förstå koden.

Några fler skäl?

Av mitt huvud? Nej, men det betyder inte att det inte finns fler.

Men om dessa är de tre som lättast kommer att tänka på, så tycker jag att de vanligtvis är de bästa anledningarna till ett givet tillvägagångssätt. Detta betyder inte att tillvägagångssättet är rätt, men de är åtminstone berättigade.