detta avsnitt är också en förutsättning för kodning, som McConnell påpekar: ”upprätta programmeringskonventioner innan du börjar programmera. Det är nästan omöjligt att ändra kod för att matcha dem senare.”

som listat nära slutet av Kodningskonventioner finns det olika konventioner för olika programmeringsspråk, så det kan vara kontraproduktivt att tillämpa samma konventioner på olika språk. Det är viktigt att notera att det inte finns någon särskild kodningskonvention för något programmeringsspråk. Varje organisation har en anpassad kodningsstandard för varje typ av mjukvaruprojekt. Det är därför absolut nödvändigt att programmeraren väljer eller utgör en viss uppsättning kodningsriktlinjer innan programvaruprojektet påbörjas. Vissa kodningskonventioner är generiska som kanske inte gäller för varje mjukvaruprojekt skrivet med ett visst programmeringsspråk.

användningen av kodningskonventioner är särskilt viktig när ett projekt involverar mer än en programmerare (det har funnits projekt med tusentals programmerare). Det är mycket lättare för en programmerare att läsa kod skriven av någon annan om all kod följer samma konventioner.

För några exempel på dåliga kodningskonventioner ger Roedy Green en lång (tung-i-kind) artikel om hur man producerar ouppnåelig kod.

CommentingEdit

på grund av tidsbegränsningar eller entusiastiska programmerare som vill ha omedelbara resultat för sin kod, kommenterar koden ofta baksätet. Programmerare som arbetar som ett team har funnit det bättre att lämna kommentarer bakom eftersom kodning vanligtvis följer cykler, eller mer än en person kan arbeta på en viss modul. Vissa kommentarer kan dock minska kostnaden för kunskapsöverföring mellan utvecklare som arbetar med samma modul.

i början av datoranvändning, en kommentar praxis var att lämna en kort beskrivning av följande:

1. modulens namn
2. modulens syfte
3. beskrivning av modulen
4. Originalförfattare
5. ändringar
6. författare som ändrade kod med en beskrivning om varför den ändrades.

”beskrivningen av modulen” ska vara så kort som möjligt men utan att offra tydlighet och omfattning.

de två sista punkterna har emellertid i stor utsträckning blivit föråldrade genom tillkomsten av revisionskontrollsystem. Ändringar och deras författarskap kan spåras på ett tillförlitligt sätt genom att använda sådana verktyg snarare än genom att använda kommentarer.

om komplicerad logik används är det också en bra praxis att lämna en kommentar ”block” nära den delen så att en annan programmerare kan förstå vad som exakt händer.

enhetstestning kan vara ett annat sätt att visa hur kod är avsedd att användas.

Naming conventionsEdit

användning av korrekta namnkonventioner anses vara god praxis. Ibland brukar programmerare använda X1, Y1, etc. som variabler och Glöm att ersätta dem med meningsfulla, vilket orsakar förvirring.

det brukar anses vara god praxis att använda beskrivande namn.

exempel: en variabel för att ta i vikt som en parameter för en lastbil kan namnges TrkWeight eller TruckWeightKilograms, med TruckWeightKilograms är att föredra, eftersom det är omedelbart igenkännbar. Se CamelCase namngivning av variabler.

Håll koden simpleEdit

koden som en programmerare skriver ska vara enkel. Komplicerad logik för att uppnå en enkel sak bör hållas till ett minimum eftersom koden kan ändras av en annan programmerare i framtiden. Logiken en programmerare implementerad kanske inte ger perfekt mening till en annan. Så håll alltid koden så enkel som möjligt.

tänk till exempel på dessa ekvivalenta rader med C-kod:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

och

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

och

return hours < 24 && minutes < 60 && seconds < 60;

den 1: A metoden, som används mycket oftare, är betydligt större än den 3: e. I synnerhet förbrukar den 5 gånger mer skärm vertikalt utrymme (linjer) och 97 tecken mot 52 (även om redigeringsverktyg kan minska skillnaden i faktisk skrivning). Det är dock diskutabelt, vilket är ”enklare”. Den första har ett uttryckligt if / then else, med ett uttryckligt returvärde som uppenbarligen är kopplat till var och en; även en nybörjare programmerare borde inte ha svårt att förstå det. Den 2: a kastar bara hängslen, skär den ”vertikala” storleken i hälften med liten förändring i konceptuell komplexitet. På de flesta språk kan ”retur” – uttalandena också bifogas de tidigare raderna, vilket ger den ”vertikala” storleken till endast en rad som den 3: e formen.

den tredje formen minimerar uppenbarligen storleken, men kan öka komplexiteten: Det lämnar de ”sanna” och ”falska” värdena implicita och blandar begreppen ”villkor” och ”returvärde”. Det är sannolikt uppenbart för de flesta programmerare, men en nybörjare kanske inte omedelbart förstår att resultatet av att utvärdera ett tillstånd faktiskt är ett värde (av typen Boolean eller motsvarande på vilket språk som helst) och därmed kan manipuleras eller returneras. I mer realistiska exempel kan 3: e formuläret ha problem på grund av operatörens företräde, kanske returnera en oväntad typ, där de tidigare formulären på vissa språk skulle rapportera ett fel. Således är” enkelhet ” inte bara en fråga om längd utan av logisk och konceptuell struktur; att göra koden kortare kan göra den mindre eller mer komplex.

För stora, långlivade program som använder verbose alternativ kan bidra till uppblåsning.

kompaktitet kan tillåta kodare att visa mer kod per sida, vilket minskar rullningsgester och tangenttryckningar. Med tanke på hur många gånger koden kan ses i processen att skriva och underhålla, kan det uppgå till en betydande besparing i programmerarens tangenttryckningar i kodens liv. Detta kanske inte verkar betydande för en student först lära sig att programmera men, när producera och upprätthålla stora program minskningen av hur många rader kod det finns möjliggör mer av koden för att passa på skärmen, mindre kod förenkling kan förbättra produktiviteten, och även minska finger, handled och ögon stam, som är vanliga medicinska problem som drabbats av produktionskoder och informationsarbetare.

Terser kodningshastigheter kompilering mycket lite, eftersom färre symboler behöver bearbetas. Dessutom kan den 3: e metoden göra det lättare att jämföra liknande kodrader, särskilt när många sådana konstruktioner kan visas på en skärm samtidigt.

slutligen kan mycket terses layouter bättre utnyttja moderna bredbildsdatorskärmar, beroende på bildskärmslayout och installation. Tidigare var skärmarna begränsade till 40 eller 80 tecken (sådana gränser har sitt ursprung långt tidigare: manuskript, tryckta böcker och till och med rullar har i årtusenden använt ganska korta linjer (se till exempel Gutenberg Bible). Moderna skärmar kan enkelt visa 200 eller fler tecken, vilket möjliggör extremt långa rader. De flesta moderna kodningsstilar och standarder tar inte upp hela bredden. Således, om du använder ett fönster så brett som skärmen, slösas mycket ledigt utrymme bort. Å andra sidan, med flera fönster, eller med hjälp av ett IDE eller annat verktyg med olika information i sidorutor, är den tillgängliga bredden för kod inom det område som är bekant från tidigare system.

det är också värt att notera att det mänskliga visuella systemet påverkas starkt av linjelängd; mycket långa rader ökar läshastigheten något, men minskar förståelsen och lägger till ögonspårningsfel. Vissa studier tyder på att längre linjer går bättre online än i tryck , men det går fortfarande bara upp till cirka 10 tum, och främst för rå hastighet för läsprosa.

PortabilityEdit

programkoden ska inte innehålla ”hårdkodade” (bokstavliga) värden som hänvisar till miljöparametrar, såsom absoluta filvägar, filnamn, användarnamn, värdnamn, IP-adresser, webbadresser, UDP / TCP-portar. Annars programmet inte kommer att köras på en värd som har en annan design än väntat. En noggrann programmerare kan parametrisera sådana variabler och konfigurera dem för värdmiljön utanför applikationen korrekt (till exempel i egenskapsfiler, på en applikationsserver eller till och med i en databas). Jämför mantraet av en”enda definitionspunkt” (SPOD).

som ett tillägg bör resurser som XML-filer också innehålla variabler snarare än bokstavliga värden, annars kommer applikationen inte att vara bärbar till en annan miljö utan att redigera XML-filerna. Till exempel, med J2EE-applikationer som körs i en applikationsserver, kan sådana miljöparametrar definieras inom ramen för JVM och applikationen ska få värdena därifrån.

ScalabilityEdit

designkod med skalbarhet som designmål eftersom det ofta i mjukvaruprojekt alltid läggs till nya funktioner i ett projekt som blir större. Därför möjlighet att lägga till nya funktioner till en programvara kodbas blir en ovärderlig metod i att skriva programvara

ReusabilityEdit

återanvändning är ett mycket viktigt designmål i mjukvaruutveckling. Återanvändning minskar utvecklingskostnaderna och minskar också tiden för utveckling om de komponenter eller moduler som återanvänds redan är testade. Mycket ofta börjar mjukvaruprojekt med en befintlig baslinje som innehåller projektet i sin tidigare version och beroende på projektet återanvänds många av befintliga mjukvarumoduler och komponenter vilket minskar utvecklings-och testtiden, vilket ökar sannolikheten för att leverera ett mjukvaruprojekt enligt schema.

konstruktionsriktlinjer i korthet

en allmän översikt över alla ovanstående: