Olen nähnyt viime aikoina useiden koodereiden kirjoittavan,
että heidän mielestään hyvä koodi [mitä on
eleganttia ja että he haluavat kirjoittaa eleganttia koodia. Olen
jotenkin onnellinen, että tämä näkökulma on pinnalla, mutta täytyy
silti sanoa, että ''elegantti'' on aika huonosti määritelty sana eikä
oikeastaan ohjaa koodin kirjoittamista yhtään mihinkään. Elegantti
tarkoittaa "näppärää, tyylikästä, hienoa". Miksi kukaan haluaisi
kirjoittaa epäeleganttia koodia? Lähinnä sanan arvo on siinä, että se
korostaa, että koodin ei pidä olla ''vain'' toimivaa vaan myös
kaunista. Mutta eikö kauneus ole katsojan silmässä?
Olen kiistellyt paljon eri koodereiden kanssa siitä, mikä
oikeastaan on kaunista. Koodin tyylikkyydessä on sama ongelma kuin
käytöstavoissa. Yhden kulttuurin (vaikkapa brasilialaisen yläluokan)
sisällä kasvaneen on vaikea nähdä, että hänen omaksumansa käytöstavat
eivät ole kaikkien näkökulmasta hyvää käytöstä; samoin yhden
koodauskulttuurin (vaikkapa [Lisp]-kulttuurin) sisällä kasvaneen on
vaikea nähdä, että hänelle päivänkirkas koodi on jollekulle muulle
esoteerista, epäkäytännöllistä tai rumaa. On tietysti taito sinänsä
osata vaihtaa kulttuuriaan ja viestiä tavalla, joka tuntuu mukavalta
vastaanottajista - oli sitten kyse koodista tai käytöksestä. Mutta
käytöstavoissa on tietty kova ydin, joka on hyvää käytöstä lähes
kulttuurista riippumatta: ole kiinnostunut, ole iloinen, näytä pitäväsi
muista, kuuntele ja yritä ymmärtää, älä tuomitse. Ja haluaisin samaan
tapaan puolustaa kantaa, että oikeasti on myös olemassa
kulttuuririippumattomasti eleganttia koodia.
Kuten käytöstavoissa, ei koodissakaan voi jättää kaikkia
kulttuurillisia näkökohtia ottamatta huomioon. Jos kirjoittaa
[Python]-koodereille, ei yksinkertaisesti voi olettaa, että
monimutkainen [listakeräelmä] avautuisi kaikille. Mutta kuten
käytöstavoissa, pitää pyrkiä myös universaalisti tyylikkääseen koodiin
- koodiin, joka on kaunista ja helppolukuista vastaanottajan
kulttuurista riippumatta. Mitä tämä kulttuuririippumattomasti
elegantti koodi oikein on? Minulla on eleganssille kolme tärkeää
''mittaria'', joita olen valmis puolustamaan. Elegantti koodi on:
# oikein nimettyä, # yksinkertaista ja # lyhyttä.
Näistä mittareista viimeinen, lyhyys, on tärkein, vähiten
ymmärretty ja sen suhteesta koodereiden tuottavuuteen on kaikkein
eniten empiiristä todistusaineistoa. Koodi on sitä parempaa, mitä
lyhyempää se on (kunhan ei murskaa täysin eleganssin
kulttuuririippuvaisia odotuksia). Tämä on minulle tärkeä väite, jonka
ilosanomaa yritän levittää. Palaan siihen tuonnempana. Tarkastellaan
ensin, mitä nämä kaikki mittarit tarkoittavat.
''Oikein nimetty'' koodi on sellaista, jossa jokainen muuttuja
nimeää hyvin sen, mitä se sisältää, ja jokainen
[funktio]/aliohjelma/metodi nimeää hyvin sen, mitä palauttaa tai
aiheuttaa. Lisäksi oliometodologiassa jokainen luokka ja rajapinta
nimeää asian, jota se edustaa kuvitteellisessa todellisuudessa, mutta
tämä ei ole niin olennaista. Tämä ei ole puhtaasti mitattava asia,
koska se riippuu muun muassa koodin lukijan tulkintakyvystä ja
kulttuurista, mutta hyvä testi on se, että luettuaan funktion nimen
ohjelmoijan pitäisi suunnilleen pystyä arvaamaan, mitä se ottaa
syötteekseen, ja luettuaan funktion nimen ja sen syötteiden nimet
ohjelmoijan pitäisi suunnilleen pystyä arvaamaan, mitä funktio tuottaa
tuloksekseen milläkin syötteillä. Katso [funktio] ja [elegantti
nimeämismalli].
''Yksinkertainen'' koodi on sellaista, jonka voi lukea helposti
ja nopeasti alusta loppuun niin, että saa järkevän kuvan siitä, mitä
kyseinen pätkä koodista tekee. Yksinkertaisuudelle on erilaisia
mittareita, kuten syklomaattinen kompleksisuus, funktioiden pituus
(hyvä maksimipituus funktiolle on 7 riviä), sekä esim. tilamuutosten,
funktioiden, olioiden ja invarianttien riippuvuuksista muodostettujen
dependenssiverkkojen konnektiivisuus ja syklien määrä ja koko. Näistä
on jonkin verran tutkimustietoa, mutta hajanaisesti. Yksinkertainen
koodi, melkein millä tahansa yllä olevista mitattuna, on nopeampaa
lukea ja helpompaa muokata rikkomatta. Jos koodi on yksinkertaista,
muuttujien ei tarvitse olla edes oikein nimettyjä. Jos muuttujan
määrittelyn saa aina pari riviä ennen käyttö(j)ä, ei muuttujan nimen
tarvitse olla kovin kuvaava.
''Lyhyt'' koodi on ihan oikeasti vain lyhyttä. Siinä on siis
vähemmän merkkejä kuin pitkässä koodissa. Hyvä koodi on lyhyttä: jos
vaikkapa säännöllisten lausekkeiden käyttö lyhentää koodia, niin se
parantaa sitä. Säännöllisten lausekkeiden, kuten muidenkin näppärien
apukeinojen, vaara on siinä, jos joku kehittäjä ei ymmärrä niitä. Mitä
osaamattomampiin kehittäjiin haluat varautua, sitä huonompaa koodia
joudut kirjoittamaan.
Lyhyt koodi on nopeampaa lukea, ihan fysiologisista syistä.
Tämä koskee sekä rivien pituutta että määrää. On tutkimusnäyttöä siitä,
että jos koodin toiminnan tajutakseen pitää lukea enemmän kuin yksi
näytöllinen koodia, lukeminen hidastuu rankasti. Vielä enemmän on
näyttöä siitä, että koodaajat tuottavat koodia samaa ''merkkitahtia''
riippumatta siitä, kuinka paljon koodi tekee. Tämä pätee kielten
välillä ja kielten sisällä: mitä pidempi ohjelma on, sitä kauemmin sen
tekeminen kestää. Niinpä koodaajien tuottavuus on sitä parempi, mitä
lyhyemmin he koodinsa kirjoittavat ja pystyvät kirjoittamaan, ja
jokainen suunnitteluperiaate, joka lisää koodin pituutta, on
lähtökohtaisesti haitallinen.
Kun puhutaan koodin ylläpidosta, on tietysti tärkeintä, että
koodin ymmärtää. Silti myös kirjoitettaessa korjauksia koodiin
ymmärtämisen ''jälkeen'' koodaukseen kuluva aika riippuu uuden koodin
määrästä. Mitä vähemmän koodia oli, sitä vähemmän sitä tarvitsee
muuttaa. Lyhyys auttaa ymmärtämisessäkin, koska isomman osan koodia
pystyy hahmottamaan kerralla, ja koska lyhyys kulkee käsi kädessä
yksinkertaisuuden kanssa.
Koodin lyhyys on erityisen hyvä mittari, koska sille on
alaraja. Tiettyä toiminnallisuutta ei voi saada aikaan mielivaltaisen
lyhyellä koodilla (pituuden alarajaa kutsutaan lopputuloksen
"Kolmogorov-kompleksisuudeksi"). Vastaavaa ylärajaa ei ole: koodia voi
aina pidentää ilman, että sen toimintatapa muuttuu.
* [kategoria: keskeneräiset] * [merkintä: 2016-02] * [atehwa] *
[kategoria: päiväkirjamerkintä] * [kategoria: kulttuuri] * [kategoria:
ohjelmointi] * [kategoria: mv-mielipide] * [muuttuja] *
http://c2.com/cgi/wiki?NumberOfKeystrokes *
http://www.connellybarnes.com/documents/language_productivity.pdf *
http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf
koodi?]