KoodiIkuisuuskysymys: koodin muotoiluKun ohjelmoidaan vähänkin isommalla porukalla, ennen pitkää joku nostaa aina kissanpöydälle koodin muotoilusta.Teksti: Jari Komppa Kuva: Annika PiiroinenMonet koodin muotoiluun liittyvistäasioista ovat makuasioita,mutta pitkälti kyse on kuitenkinoptimoinnista. Ei siis koodin nopeuttamisestatai muusta tehostamisesta vaan ohjelmointiprosessinparantamisesta. Muotoiluaoptimoimalla voidaan saada aikaanparempaa ohjelmakoodia nopeammin.Tietokoneiden alkupäivistä lähtien onollut selvää, että suurin osa ohjelmoinnistaon bugien metsästystä eli koodinlukemista. Niinpä kannattaakin kirjoittaakoodia siten, että se on mahdollisimmanhelppolukuista. Kääntäjät kehittyvät jatkuvastija ovat pitkään olleet niin hyviä,että koodin kirjoittamisessa kannattaamieluummin ajatella koodin luettavuuttakuin kääntäjää.Käytössä on monenlaisia muotoilukäytäntöjäeli koodauskonventioita. Toisessaääripäässä ovat käytännöt, joissapyritään säästämään mahdollisimmanpaljon tilaa ja näppäinpainalluksia. Tällätavoin pieneenkin tietokoneen ruudullaolevaan ikkunaan mahtuu näkyviin paljonkoodia. Toisessa ääripäässä ovat käytännöt,jotka tuottavat ilmavaa, helppolukuistakoodia.se, joka näytti vaativan enemmän työtä.Muotoiluohjeet kannattaisi pitää parinkolmen sivun mittaisena, sillä muutenkasvaa riski, että niitä ei noudateta.Mainitun pelifirman ohje oli 22-sivuinen,mutta silti sitä seurattiin lähes pilkulleen.Lopputuloksena oli helposti ymmärrettäväälähdekoodia, ja työntekijät alkoivatkäyttää samaa muotoilua myös joissakinharrastusprojekteissaan.Tämä artikkeli ei käy koko muotoilukäytäntöäläpi mutta antaa esimerkkejätärkeimmistä asioista. Mikäli tätä lukiessasitunnet yhtäkkiä raivon nousevan, älähuoli, sillä nyt puhutaan asioista, joistajoka tapauksessa kiistellään maailmantappiin asti.Kielenä tässä on C tai C++, mutta samatasiat koskevat kaikkia C:n sukuisiakieliä.SisennyksetSisennykset ovat jostain syystä hyvinkiistelty seikka. Yleisimmin sisennyksissäkäytetään kahta tai neljää välilyöntiä,joskin kahdeksaakin näkee välillä. Neljänvälilyönnin puolesta puhuu lähinnäse, että se on Visual Studion oletusarvo.Eräässä virallisessa dokumentissa päädyttiinkolmen välilyönnin kompromissiin.Käytännössä sisennyksen suuruudellaei ole väliä niin kauan, kun siinäollaan johdonmukaisia.Sarkaimet toimivat eri tavoin eriteksti editoreilla, joten sisennykset ja tasauksetkannattaa tallentaa tiedostoihinaina välilyönneillä. Listauksessa 1 onesimerkki, kuinka muotoilu voi räjähtääsarkainasetusten muuttuessa.Ongelmat voi välttää käyttämällä sarkainmerkkejäpelkästään sisennykseen.Käytännössä tämäkin johtaa helpostisiihen, että osa koodista seuraa oikeaamuotoilua ja osa ei. Helpoiten sotkustapääsee määräyksellä, että kaikkialla käytetäänvälilyöntejä.Aaltosulkeiden paikkaAaltosulkeilla määritellään koodilohko, jasiksi niiden kannattaa olla samalla tasollasisennyksen kanssa. Aaltosulkeita kannattaakäyttää luettavuuden lisäämiseksimyös siellä, missä niiden käyttö on vapaaehtoista.Listauksessa 2 on esimerkkihuonosta ja hyvästä käytännöstä.Neuvottelun tulosErään pelifirman alkuvaiheissa ohjelmoijaporukkaistui neuvottelutilassa muutamanpäivän riitelemässä kasaan muotoiluohjeen.Usein ihan pikkuseikoissakinpiti valita useamman vaihtoehdon välillä,ja äänestykset voitti jokaisessa kohdassakompleksi(parametri1, parametri2, parametri3,parametri4, parametri5, parametri6,parametri7, parametri8, parametri9);kompleksi(parametri1, parametri2, parametri3,parametri4, parametri5, parametri6,parametri7, parametri8, parametri9);Listaus 1. Sarkainasetusten muuttaminen muuttaa koodin muotoilua.12 2014.1
EtuliitteetMuuttujien nimissä käytetään toisinaanetuliitteitä, jotka kertovat muuttujanominaisuuksista. Kuuluisin näistä onniin sanottu unkarilainen notaatio, jossamuuttujien nimen alkuun merkitäänmuuttujatyyppi. Esimerkiksi muuttujanimeltä plAddress on osoitin 32-bittiseensanaan. Muun muassa Windowsin ohjelmointirajapintakäyttää unkarilaista notaatiota.Etuliitteet ovat monella tavalla huonoidea. Ne eivät helpota koodin ymmärtämistäjuuri ollenkaan, ja muuttujien tyypinvaihtuessa on vanha nimi korvattavakaikkialta koodista uudella. Vaihtoehtonaon hyväksyä tilanne, jossa etuliite ei oletae muuttujan tyypistä. Surullisenkuuluisaesimerkki tästä on 32-bittisessäWindowsissa olevan WinMain-funktionparametri wParam, joka ei nimestäänhuolimatta ole 16-bittinen kokonaisluku.Microsoft ei vaihtanut muuttujan nimeä,koska se halusi säilyttää yhteensopivuuden16-bittisen Windowsin kanssa.Etuliitettä kannattaa mieluumminkäyttää ilmaisemaan muuttujan näkyvyysaluetta,esimerkiksi seuraavan esimerkintavoin:aParametriMuuttujamJäsenMuuttujagGlobaaliMuuttujapaikallinenMuuttujaVAKIO_ARVOLuokanTyyppiTämä käytäntö tekee koodista selvempää,koska koodi selittää itseään.Lyhyestäkin koodinpätkästä alkaa ymmärtääasioita, eikä termien merkityksiätarvitse enää metsästellä sieltä täältäniin paljon. Vertaa listauksessa 3 oleviakoodinpätkiä.Yksi rivi, yksi asiaIlmavaa koodia on helpompaa lukea jaymmärtää kuin tiivistä. Hyvä periaate on,että yhdellä rivillä ilmaistaan vain yksiasia. Valitettavasti varsinkin C-kielessäon hyvin helppoa kirjoittaa koodia, jossayksi rivi tekee monia asioita. Niin on tehtyesimerkiksi strcpy-funktiossa (listaus4).Kokenut ohjelmoija toki ymmärtäätiivistäkin koodia, mutta strcpy-funktionvoi kirjoittaa huomattavasti helpomminymmärrettäväksi. Jos muutaman sadanrivin mittainen funktio sisältää runsaastivastaavanlaisia kikkoja, lopputulostaalkaa olla hyvin vaikeaa ymmärtää. Listauksessa5 on strcpy:n koodi ilmavammintoteutettuna. Pätevä kääntäjä tuottaakummastakin täysin samanlaisenlopputuloksen.VälilyönnitMyös selventävä välilyöntien käyttö kuuluukoodin typografiaan. Jotta koodi olisimahdollisimman luettavaa, kannattaakirjoittaa välilyönti operaattoreiden molemminpuolin, for- ja if-termien jälkeensekä pilkkujen ja puolipisteiden jälkeen.Listauksessa 6 näkyy välilyöntien vaikutuskoodin luettavuuteen. Lausekkeeterottuvat hyvin toisistaan.void bah() {for(i=0;i
Change language