Tick-the-Code - koodiesimerkit
| MAGIC-tikit |
|---|
Jopa nollat, jopa alustusarvot, sisältävät taikuutta.
Asiayhteydestä riippumatta merkkijonot tulee tikata jatkoanalyysia varten. Jos merkkijonot on siroteltu ympäri koodia, kuinka vaivalloista onkaan tehdä kieliversio moduulista? On myös helpompi tarkistaa merkkijonojen johdonmukaisuus, jos ne on koottu yhteen paikkaan. Debug-tulostuksissa johdonmukaisuus on erityisen tärkeää.
Tässä on erinomainen esimerkki taikanumeroiden kasautumistaipumuksesta. Nämä numerot liittyvät todennäköisesti hyvinkin läheisesti muihin numeroihin. Koodi kehittyy ja muuttuu. Kuinka helppoa on muuttaa tällaista koodia rikkomatta sitä?
Sääntö koskee KAIKKIA numeroita, kirjainvakioita ja merkkijonoja. Useimmissa tapauksissa luovan ja merkityksellisen nimen käyttäminen on kannattavampaa kuin vakioarvon nykäiseminen hihasta tai hatusta. Tällä säännöllä taikavakiot löytyvät. Koodin ylläpitäjän (kirjoittajan) tehtäväksi jää ottaa tikit vakavasti ja toimia oikein.
|
| ELSE-tikit |
Tässä on selvä ELSE-rikkomus. Ehkä mitään ei tarvitse tehdä, jos ehtolauseke on epätosi - mutta koodi pitää sen salaisuutenaan. Ylläpitäjän täytyy vain olettaa, että koodi on kunnossa. Ja sehän tiedetään, ettei tilanne aina ole niin.
Tässä on pari erityisen ikävää ELSE-rikkomusta. Sisennyksessä on selvästi jotain pielessä. Toinen if on selvästi sisennetty aivan kuin se kuuluisi ylempään if-lohkoon. Minkään lohkon ympärillä ei kuitenkaan ole kaarisulkuja sen osoittamiseksi. Tässä olisi siis kaksi PTHESES-säännön rikkomustakin.
Else-haarassa ei todellakaan ole koodia. Onko se tarkoituksellista vai vahinko? Sitä ei voi varmaksi sanoa. Voimme vain yrittää päätellä sen ympäröivästä koodista ja toivoa löytävämme ajantasaisen ja asiaankuuluvan kommentin, joka mainitsee ettei puuttuvia osia tarvita. Muuten olemme pulassa.
Olisi niin helppoa kirjata ylös ajatus: "Tässä ei tarvita koodia, jos ehto on epätosi." Pelkästään kommentti /* no else */ kertoisi lukijalle suoraan, että else-haaraa harkittiin ja se todettiin tarpeettomaksi. Noudattamalla tätä tapaa tarvitsee epäillä ainoastaan niitä if-ehtoja, joissa ei ole else-haaraa eikä 'noelse'-kommenttia.
|
| TAG-tikit |
Tämä TAG-rikkomus on helppo löytää, "XXX" on selkeä todiste merkkikommentista. Se suorastaan kerjää huomiota.
Kommentti kysymyksen muodossa huutaa "EPÄVARMA"! Onko koodi oikein vai ei? Onko koodi valmista vai ei? Tällaiset kohdat voivat olla hyvinkin vaarallisia.
"Kovakoodattu toistaiseksi"? "Toistaiseksi"? Milloin se muutetaan? Ennen tuotantoversiota? Ennen vuoden loppua? Eilen?
Lähdekoodissa ei ole tilaa epävarmuudelle. Huonoimmat kehittäjät saattavat olla erinomaisia epävarmuuden piilottamisessa, mikä on erinomaisen PAHA asia. Ne joiden taidot eivät aina riitä, mutta jotka ovat rehellisiä, kirjaavat puutteensa kommenttiin. Epävarmuuden ja virhealttiin koodin pystyy hyvin tunnistamaan näiden erinomaisten vihjeiden avulla.
Kun koodia tikkaa tarpeeksi, törmää kommentteihin tietyistä kääntäjäversioista, tai muihin mainintoihin työkaluista tai ympäristön kummallisuuksista. Jos koodi on tarpeeksi vanhaa, kommentit saattavat viitata ikivanhoihin ongelmiin. Niiden aika voi olla jo ohi. Käytä TAG-tikkejä tällaisten kommenttien analysointiin ja poista vanhentuneet kuonat koodista.
|
| NULL-tikit |
Tämän esimerkki saattaa olla jo tuttu ELSE-tikeistä. Usein tikit parveilevatkin. On tärkeää tikata kukin sääntörikkomus erikseen ja merkitä niihin kyseisen säännön nimi. Ellei tikkaa jotakin rikkomusta, on turha odottaa sen häviävän koodista.
'Release'-avainsanan avulla on hyvä etsiä NULL-rikkomuksia. Jotain on silloin päättynyt. Juuri vapautettuun resurssiin viittaavat osoittimet kannattaa ehkä nollata, ettei kukaan tule käyttäneeksi niitä vahingossa.
Jossain vaiheessa CLOSURE-sääntö korvasi NULL-säännön. NULL-sääntö koski vain osoittimia, CLOSURE pätee kaikenlaisiin resursseihin. Kyseessä voi olla tiedoston sulkeminen, dynaamisen muistin vapauttaminen, tietokantayhteyden tai pistukan (socket) sulkeminen.
|
| PTHESES-tikit |
Laskutoimitusten joukko on varsinainen bugien kasvualusta. Sulkujen käyttäminen halutun laskujärjestyksen osoittamiseen voi tehdä koodista ainoastaan selkeämpää. Erityisen tärkeää tämä on, kun joku haluaa muuttaa koodia lisäämällä yhtälöön termin "+ 1".
Ensinnäkin tässä koodinpätkässä on taikanumeroita (sääntöjen nimet eivät näy kuvassa, vain violetit ympyrät). Lisäksi joukossa on erilaisia operaattoreita: "&", "<<" ja jopa joitain sulkuja. Väittäisin kuitenkin, että muutama puuttuu. Olisi tietysti mahdollista tarkistaa laskujärjestys operaattorien laskujärjestystaulukosta, mutta miksi nähdä vaivaa? Miksei vain lisätä sulkuja ja merkitä oikea laskujärjestys selvästi - on se sitten laskujärjestystaulukon mukainen tai ei? Mitä menetettävää on? Bugi tai pari, sanoisin.
Koodin tulee ilmaista kaikki selvästi ja yksityiskohtaisesti niin, ettei sitä voi ymmärtää väärin tai epäillä.
|
| CALL-tikit |
Nämä kaksi riviä näyttäisivät kuuluvan yhteen. Monissa kohdin esimerkkikoodia niitä molempia joko muutettiin tai luettiin samanaikaisesti. Ne kannattanee pakata yhteen ja samaan rutiiniin.
Muteksin käsittely vaikuttaa melko selkeältä, mutta on siinä kuitenkin kuusi riviä koodia. Esimerkkikoodissa samat kuusi riviä muuten toistuivat useasti. Muteksia käytetään, jotta koodi toimisi oikein, mutta aina ei tarvitse nähdä kaikkia yksityiskohtia. Kun yksityiskohdat piilotetaan omaan, uuteen rutiiniinsa, voi keskittyä varsinaiseen asiaan rauhassa.
CALL-tikkien tulkinta ei ole aina ihan niin suoraviivaista kuin esimerkit kenties antavat ymmärtää. Joskus on syytä ajatella abstraktioita hieman laajemmin, ja yksikin CALL-rikkomus voi aiheuttaa arkkitehtuurin massiivisen uudelleenorganisoinnin. Jos koodin abstraktiot ovat aivan pielessä, siitä on turha syyttää CALL-sääntöä. Sääntö vain auttaa huomaamaan suunnitteluvikoja, jotka pitää hoitaa kuntoon muutenkin.
|
Päivitetty viimeksi: 9.2.09.
Tick-the-Code käytännössä:
MAGIC-sääntö.
Olet nyt tässä:
Klikkaamalla sivustokarttaan.
Osanottajien sanomaa:
Klikkaamalla kurssitietoihin.
