Tämä osio on myös todella edellytys koodaukselle, kuten McConnell huomauttaa: ”Laadi ohjelmointikäytäntöjä ennen ohjelmoinnin aloittamista. On lähes mahdotonta muuttaa koodia vastaamaan niitä myöhemmin.”

kuten Koodauskonventioiden loppupuolella on lueteltu, eri ohjelmointikielille on olemassa erilaisia konventioita, joten samojen konventioiden soveltaminen eri kieliin voi olla haitallista. On tärkeää huomata, että ohjelmointikielelle ei ole olemassa yhtä tiettyä koodauskäytäntöä. Jokaisella organisaatiolla on oma koodausstandardi kullekin ohjelmistoprojektityypille. Siksi on välttämätöntä, että ohjelmoija valitsee tai laatii tietyn koodausohjeistuksen ennen ohjelmistoprojektin aloittamista. Jotkut koodauskäytännöt ovat yleisiä, jotka eivät välttämättä päde jokaiseen tietyllä ohjelmointikielellä kirjoitettuun ohjelmistoprojektiin.

koodauskonventioiden käyttö on erityisen tärkeää silloin, kun projektissa on mukana useampi kuin yksi ohjelmoija (projekteja on ollut tuhansia ohjelmoijia). Ohjelmoijan on paljon helpompi lukea jonkun muun kirjoittamaa koodia, jos kaikki koodi noudattaa samoja käytäntöjä.

joillekin esimerkeille huonoista koodauskonventioista Roedy Green tarjoaa pitkähkön (kieli poskessa) artikkelin siitä, miten tuottaa saavuttamatonta koodia.

kommentointi

aikarajoitusten tai innokkaiden ohjelmoijien takia, jotka haluavat koodilleen välittömiä tuloksia, koodin kommentointi jää usein taka-alalle. Tiiminä työskentelevät ohjelmoijat ovat huomanneet, että on parempi jättää kommentit taakse, koska koodaus seuraa yleensä syklejä, tai useampi kuin yksi henkilö voi työskennellä tietyn moduulin parissa. Jotkut kommentoinnit voivat kuitenkin vähentää samalla moduulilla työskentelevien kehittäjien välisen tiedonsiirron kustannuksia.

tietojenkäsittelyn alkuaikoina eräs kommentointikäytäntö oli jättää lyhyt kuvaus seuraavista:

1. moduulin nimi
2. moduulin tarkoitus
3. kuvaus moduulista
4. alkuperäinen tekijä
5. muutokset
6. tekijät, jotka muokkasivat koodia kuvauksella siitä, miksi sitä muutettiin.

”moduulin kuvauksen” tulisi olla mahdollisimman lyhyt, mutta selkeydestä ja kattavuudesta tinkimättä.

kaksi viimeistä kappaletta ovat kuitenkin pitkälti vanhentuneet versionhallintajärjestelmien tulon myötä. Muutoksia ja niiden tekijyyttä voidaan luotettavasti seurata tällaisten työkalujen avulla kommenttien sijaan.

myös, jos käytetään monimutkaista logiikkaa, on hyvä käytäntö jättää kommentin ”block” tuon osan lähelle, jotta toinen ohjelmoija voi ymmärtää, mitä tarkalleen ottaen tapahtuu.

yksikkötestaus voi olla toinen tapa osoittaa, miten koodia on tarkoitus käyttää.

Nimeämiskonventiotedit

kunnollisten nimeämiskäytäntöjen käyttöä pidetään hyvänä käytäntönä. Joskus ohjelmoijat pyrkivät käyttämään X1: tä, Y1: tä jne. muuttujina ja unohtaa korvata ne merkityksellisillä, aiheuttaen sekaannusta.

kuvailevien nimien käyttöä pidetään yleensä hyvänä käytäntönä.

esimerkki: muuttuja, jolla paino otetaan Kuorma-auton parametriksi, voidaan nimetä Trkkweight-tai Truckweightkilogrammoiksi, jolloin Truckweightkilogrammit ovat suositeltavampia, koska ne ovat heti tunnistettavissa. Katso CamelCase nimeäminen muuttujia.

Pidä koodi yksinkertaisena

ohjelmoijan kirjoittaman koodin tulisi olla yksinkertainen. Monimutkainen logiikka yksinkertaisen asian saavuttamiseksi tulisi pitää minimissä, koska koodi saattaa olla toisen ohjelmoijan muokkaama tulevaisuudessa. Yhden ohjelmoijan toteuttama logiikka ei välttämättä ole täysin järkevä toiselle. Joten, aina pitää koodi mahdollisimman yksinkertainen.

esimerkiksi nämä vastaavat C-koodin rivit:

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

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

ja

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

paljon yleisemmin käytetty 1.lähestymistapa on huomattavasti suurempi kuin 3. Erityisesti, se kuluttaa 5 kertaa enemmän näytön pystysuunnassa tilaa (linjat), ja 97 merkkiä verrattuna 52 (vaikka muokkaustyökalut voivat vähentää eroa todellinen kirjoittamalla). Se on kuitenkin argumentoitavissa, mikä on ”yksinkertaisempi”. Ensimmäinen on eksplisiittinen if / then else, jossa eksplisiittinen palautusarvo liittyy ilmeisesti jokaiseen; jopa aloittelevalla ohjelmoijalla ei pitäisi olla vaikeuksia ymmärtää sitä. 2nd vain heittää henkselit, leikkaus ”pystysuora” koko puoli vähän muutoksia käsitteellinen monimutkaisuus. Useimmissa kielissä ”return” – lauseet voitiin liittää myös edeltäviin riveihin, jolloin ”vertical” – koko saatiin vain yhteen riviin, joka on 3.

kolmas muoto ilmeisesti minimoi koon, mutta saattaa lisätä monimutkaisuutta: Se jättää” tosi ”ja” epätosi ”arvot implisiittisiksi ja sekoittaa käsitteet” ehto ”ja”palautusarvo”. Se on todennäköisesti ilmeinen useimmille ohjelmoijille, mutta noviisi ei välttämättä heti ymmärrä, että ehdon arvioinnin tulos on itse asiassa arvo (tyyppi Boolean, tai sen vastine millä kielellä tahansa), ja siten voidaan manipuloida tai palauttaa. Realistisemmissa esimerkeissä, 3rd lomake voi olla ongelmia johtuu operaattorin etuoikeus, ehkä palauttaa odottamaton tyyppi, jossa aiemmat lomakkeet olisi joissakin kielissä ilmoittaa virhe. ”Yksinkertaisuudessa” ei siis ole kyse pelkästään pituudesta, vaan loogisesta ja käsitteellisestä rakenteesta; koodin lyhentäminen voi tehdä siitä vähemmän tai monimutkaisemman.

suurille, pitkäikäisille ohjelmille, joissa käytetään monisanaisia vaihtoehtoja, voi olla omiaan aiheuttamaan paisumista.

tiiviys voi antaa koodaajille mahdollisuuden tarkastella enemmän koodia sivua kohden, mikä vähentää vierittäviä eleitä ja näppäilyjä. Kun otetaan huomioon kuinka monta kertaa koodia voidaan tarkastella kirjoittamisen ja ylläpidon aikana, se voi olla merkittävä säästö ohjelmoijan näppäilyissä koodin elämässä. Tämä ei ehkä tunnu merkittävältä oppilaalle, joka ensin opettelee ohjelmoimaan, mutta kun tuotetaan ja ylläpidetään suuria ohjelmia, kuinka monta riviä koodia on mahdollista, että enemmän koodia mahtuu näytölle, pieni koodin yksinkertaistaminen voi parantaa tuottavuutta ja myös vähentää sormen, ranteen ja silmien rasitusta, jotka ovat yleisiä lääketieteellisiä ongelmia, joita tuotannon koodarit ja tietotyöntekijät kärsivät.

Terser-koodaus nopeuttaa koostamista hyvin vähän, koska vähemmän symboleja tarvitsee käsitellä. Lisäksi, 3rd lähestymistapa voi sallia samanlaisia rivejä koodin on helpompi vertailla, varsinkin kun monet tällaiset konstruktiot voivat näkyä yhdellä näytöllä samanaikaisesti.

lopuksi hyvin terseissä ulkoasuissa saatetaan käyttää paremmin nykyaikaisia laajakuvatietokonenäyttöjä näytön layoutista ja asetuksista riippuen. Aiemmin ruudut rajoittuivat 40 tai 80 merkkiin (tällaiset rajat ovat peräisin paljon aikaisemmin: käsikirjoituksissa, painetuissa kirjoissa ja jopa kääröissä on vuosituhansien ajan käytetty melko lyhyitä viivoja (KS.esimerkiksi Gutenbergin Raamattu). Nykyaikaiset näytöt voivat helposti näyttää 200 merkkiä tai enemmän, mikä mahdollistaa erittäin pitkät linjat. Useimmat nykyaikaiset koodaustyylit ja standardit eivät kestä koko leveyttä. Jos siis käytetään yhtä yhtä leveää ikkunaa kuin näyttö, paljon käytettävissä olevaa tilaa menee hukkaan. Toisaalta, kun käytetään useita ikkunoita tai IDE: tä tai muuta työkalua, jossa on erilaisia tietoja sivupaneeleissa, koodin käytettävissä oleva leveys on aiemmista järjestelmistä tuttua luokkaa.

on myös syytä huomata, että viivan pituus vaikuttaa suuresti ihmisen näköjärjestelmään; hyvin pitkät jonot lisäävät hieman lukunopeutta, mutta vähentävät ymmärtämistä ja lisäävät katseenseurantavirheitä. Joidenkin tutkimusten mukaan pidemmät jonot pärjäävät paremmin verkossa kuin painettuna , mutta tämä menee silti vain noin 10 tuumaan ja lähinnä raakaan proosan lukemisen nopeuteen.

PortabilityEdit

ohjelmakoodi ei saa sisältää ”kovakoodattuja” (kirjaimellisia) arvoja, jotka viittaavat ympäristöparametreihin, kuten absoluuttisiin tiedostopolkuihin, tiedostonimiin, käyttäjänimiin, isäntänimiin, IP-osoitteisiin, URL-osoitteisiin, UDP / TCP-portteihin. Muussa tapauksessa sovellus ei toimi palvelimella, jonka rakenne on erilainen kuin oletettiin. Huolellinen ohjelmoija voi parametrisoida tällaiset muuttujat ja määrittää ne isännöintiympäristöön varsinaisen sovelluksen ulkopuolella (esimerkiksi ominaisuustiedostoissa, sovelluspalvelimessa tai jopa tietokannassa). Vertaa mantraa ”yhden pisteen määritelmä” (SPOD).

laajennuksena resurssien, kuten XML-tiedostojen, tulisi sisältää myös muuttujia kirjaimellisten arvojen sijaan, muuten sovellus ei ole siirrettävissä toiseen ympäristöön muokkaamatta XML-tiedostoja. Esimerkiksi J2EE-sovellusten ollessa käynnissä sovelluspalvelimessa tällaiset ympäristöparametrit voidaan määritellä JVM: n soveltamisalalla ja sovelluksen pitäisi saada arvot sieltä.

Skaalautuvuusedit

Suunnittelukoodi, jonka suunnittelutavoitteena on skaalautuvuus, koska hyvin usein ohjelmistoprojekteissa isommaksi muuttuvaan projektiin lisätään aina uusia ominaisuuksia. Siksi mahdollisuus lisätä uusia ominaisuuksia ohjelmistokoodipohjaan tulee korvaamattomaksi menetelmäksi kirjoitettaessa ohjelmistoja

ReusabilityEdit

uudelleenkäyttö on erittäin tärkeä suunnittelutavoite ohjelmistokehityksessä. Uudelleenkäyttö vähentää kehityskustannuksia ja lyhentää myös kehitysaikaa, jos Uudelleen käytettävät komponentit tai moduulit on jo testattu. Hyvin usein ohjelmistoprojektit alkavat olemassa olevasta perustasosta, joka sisältää projektin sen aikaisemman version ja projektista riippuen monia olemassa olevia ohjelmistomoduuleja ja-komponentteja käytetään uudelleen, mikä vähentää kehitys-ja testausaikaa, mikä lisää todennäköisyyttä toimittaa ohjelmistoprojekti aikataulussa.

rakentamisohjeet lyhyesti

yleiskuva kaikista edellä mainituista: