denne delen er også egentlig en forutsetning for koding, Som McConnell påpeker: «Opprett programmeringskonvensjoner før du begynner å programmere. Det er nesten umulig å endre kode for å matche dem senere.»

som oppført nær Slutten Av Kodingskonvensjoner, er det forskjellige konvensjoner for forskjellige programmeringsspråk, så det kan være kontraproduktivt å anvende de samme konvensjonene på tvers av forskjellige språk. Det er viktig å merke seg at det ikke er noen spesiell kodingskonvensjon for noe programmeringsspråk. Hver organisasjon har en tilpasset kodingsstandard for hver type programvareprosjekt. Det er derfor viktig at programmereren velger eller utgjør et bestemt sett med kodingsretningslinjer før programvareprosjektet starter. Noen kodingskonvensjoner er generiske som kanskje ikke gjelder for hvert programvareprosjekt skrevet med et bestemt programmeringsspråk.bruk av kodekonvensjoner er spesielt viktig når et prosjekt involverer mer enn en programmerer (det har vært prosjekter med tusenvis av programmerere). Det er mye lettere for en programmerer å lese kode skrevet av noen andre hvis all kode følger de samme konvensjonene.For noen eksempler på dårlig koding konvensjoner, Gir Roedy Green en lang (tongue-in-cheek) artikkel om hvordan å produsere uoppnåelig kode.

Commenteringedit

på grunn av tidsbegrensninger eller entusiastiske programmerere som ønsker umiddelbare resultater for koden, tar kommentering av kode ofte baksetet. Programmerere som jobber som et team har funnet det bedre å legge igjen kommentarer siden koding vanligvis følger sykluser, eller mer enn en person kan jobbe på en bestemt modul. Noen kommentarer kan imidlertid redusere kostnadene ved kunnskapsoverføring mellom utviklere som arbeider på samme modul.

I de tidlige dagene av databehandling var en kommentarpraksis å legge igjen en kort beskrivelse av følgende:

1. Navnet på modulen
2. Formålet Med Modulen
3. Beskrivelse Av Modulen
4. Original Forfatter
5. Modifikasjoner
6. Forfattere som endret kode med en beskrivelse av hvorfor den ble endret.

«beskrivelse av modulen» skal være så kort som mulig, men uten å ofre klarhet og helhet.

imidlertid har de to siste elementene i stor grad blitt foreldet av adventen av revisjonskontrollsystemer. Modifikasjoner og deres forfatterskap kan spores pålitelig ved å bruke slike verktøy i stedet for ved å bruke kommentarer.Også, hvis komplisert logikk blir brukt, er det en god praksis å legge igjen en kommentar» blokk » nær den delen slik at en annen programmerer kan forstå hva som skjer.

Enhetstesting kan være en annen måte å vise hvordan koden er ment å brukes.

Naming conventionsEdit

Bruk av riktige navnekonvensjoner anses som god praksis. Noen ganger programmerere pleier Å bruke X1, Y1, etc. som variabler og glem å erstatte dem med meningsfulle, forårsaker forvirring.

det er vanligvis ansett som god praksis å bruke beskrivende navn.

Eksempel: en variabel for å ta i vekt som parameter for en lastebil kan bli kalt TrkWeight Eller TruckWeightKilograms, Med TruckWeightKilograms å foretrekke, siden Det er umiddelbart gjenkjennelig. Se CamelCase navngiving av variabler.

Hold koden simpleEdit

koden som en programmerer skriver, skal være enkel. Komplisert logikk for å oppnå en enkel ting bør holdes til et minimum siden koden kan endres av en annen programmerer i fremtiden. Logikken en programmerer implementert kan ikke gi perfekt mening til en annen. Så hold alltid koden så enkel som mulig.

tenk for eksempel på disse ekvivalente linjene Med C-kode:

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

og

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

og

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

1.tilnærming, Som Er mye mer vanlig, er betydelig større enn 3. Spesielt bruker den 5 ganger mer skjerm vertikal plass( linjer) og 97 tegn mot 52 (selv om redigeringsverktøy kan redusere forskjellen i faktisk skriving). Det er argumenterbart, men som er «enklere». Den første har en eksplisitt if / then else, med en eksplisitt returverdi åpenbart knyttet til hver; selv en nybegynner programmerer burde ikke ha problemer med å forstå det. 2nd forkaster bare bøylene, kutter den «vertikale» størrelsen i halv med liten endring i konseptuell kompleksitet. På de fleste språk kan «return» – setningene også legges til de tidligere linjene, og bringer den «vertikale» størrelsen til bare en linje som 3.form.

den tredje formen minimerer åpenbart størrelsen, men kan øke kompleksiteten: Det etterlater de» sanne «og» falske » verdiene implisitte, og blander begrepene «tilstand» og «returverdi». Det er sannsynligvis åpenbart for de fleste programmerere, men en nybegynner kan ikke umiddelbart forstå at resultatet av å evaluere en tilstand faktisk er en verdi( av Typen Boolsk eller tilsvarende i hvilket språk som helst), og dermed kan manipuleres eller returneres. I mer realistiske eksempler kan 3rd-skjemaet ha problemer på grunn av operatørpreferanse, kanskje returnere en uventet type, der de tidligere skjemaene på noen språk ville rapportere en feil. Således er» enkelhet » ikke bare et spørsmål om lengde, men av logisk og konseptuell struktur; å lage kode kortere kan gjøre det mindre eller mer komplekst.

for store, langlivede programmer som bruker verbose alternativer kan bidra til oppblåsthet.

Kompakthet kan tillate kodere å vise mer kode per side, redusere rulle bevegelser og tastetrykk. Gitt hvor mange ganger koden kan sees i ferd med å skrive og vedlikeholde, kan det utgjøre en betydelig besparelse i programmerer tastetrykk i livet til koden. Dette kan ikke virke signifikant for en student som først lærer å programmere, men når man produserer og vedlikeholder store programmer, reduserer reduksjonen av hvor mange kodelinjer det er mulig for mer av koden å passe på skjermen, kan mindre kodeforbedring forbedre produktiviteten, og også redusere finger -, håndledd-og øyestamme, som er vanlige medisinske problemer som produksjonskodere og informasjonsarbeidere lider av.

Terser koding hastigheter kompilering svært lite, som færre symboler må behandles. Videre kan den 3. tilnærmingen tillate lignende linjer med kode å bli lettere sammenlignet, spesielt når mange slike konstruksjoner kan vises på en skjerm samtidig.

Endelig kan svært terses oppsett bedre utnytte moderne widescreen dataskjermer, avhengig av skjerm layout og oppsett. Tidligere var skjermene begrenset til 40 eller 80 tegn (slike grenser oppsto langt tidligere: manuskripter, trykte bøker og til og med ruller har i årtusener brukt ganske korte linjer (se For Eksempel Gutenberg Bible). Moderne skjermer kan enkelt vise 200 eller flere tegn, slik at ekstremt lange linjer. De fleste moderne kodingsstiler og standarder tar ikke opp hele bredden. Dermed, hvis du bruker ett vindu så bredt som skjermen, mye ledig plass er bortkastet. På den annen side, med flere vinduer, eller ved HJELP AV EN IDE eller et annet verktøy med forskjellig informasjon i sideruter, er den tilgjengelige bredden for kode i området kjent fra tidligere systemer.Det er også verdt å merke seg at det menneskelige visuelle systemet er sterkt påvirket av linjelengden; svært lange linjer øker lesehastigheten litt, men reduserer forståelsen og legger til øyesporingsfeil. Noen studier tyder på at lengre linjer fare bedre på nettet enn på trykk , men dette fortsatt bare går opp til ca 10 inches, og hovedsakelig for rå hastighet på lesing prosa.

PortabilityEdit

Programkoden skal ikke inneholde» hardkodede » (bokstavelige) verdier som refererer til miljøparametere, for eksempel absolutte filbaner, filnavn, brukernavn, vertsnavn, IP-adresser, Nettadresser, UDP/TCP-porter. Ellers vil programmet ikke kjøre på en vert som har en annen design enn forventet. En forsiktig programmerer kan parameterisere slike variabler og konfigurere dem for vertsmiljøet utenfor applikasjonen som er riktig (for eksempel i eiendomsfiler, på en applikasjonsserver eller til og med i en database). Sammenlign mantraet til et «single point of definition» (SPOD).

som en utvidelse bør ressurser som XML-filer også inneholde variabler i stedet for bokstavelige verdier, ellers vil programmet ikke være bærbart til et annet miljø uten å redigere XML-filene. FOR EKSEMPEL, MED J2EE-programmer som kjører i en applikasjonsserver, kan slike miljøparametere defineres i omfanget AV JVM, og programmet skal få verdiene derfra.

Skalerbarhetredigert

Designkode med skalerbarhet som designmål fordi det ofte legges til nye funksjoner i et prosjekt som blir større i programvareprosjekter. Derfor blir anlegget for å legge til nye funksjoner i en programvarekodebase en uvurderlig metode for å skrive programvare

ReusabilityEdit

Gjenbruk er et svært viktig designmål i programvareutvikling. Gjenbruk reduserer utviklingskostnadene og reduserer også tiden for utvikling dersom komponentene eller modulene som gjenbrukes allerede er testet. Svært ofte starter programvareprosjekter med en eksisterende grunnlinje som inneholder prosjektet i sin tidligere versjon, og avhengig av prosjektet blir mange eksisterende programvaremoduler og komponenter gjenbrukt som reduserer utviklings-og testtid, og øker dermed sannsynligheten for å levere et programvareprosjekt i tide.

Konstruksjonsretningslinjer i korthetrediger

en generell oversikt over alt ovenfor: