TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1
Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu 4) Nimeäminen 5) Funktiot 6) Koodin kommentointi 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 2
Mitä on hyvä koodi? "Any fool can write code that a computer can understand. Good Programmers write code that humans can understand - Martin Fowler Ohjelmakoodin lukemiseen käytetään vähintään 10 kertaa enemmän aikaa kuin sen kirjoittamiseen! Ero kasvaa ajan kuluessa suuremmaksi. Ohjelmoijat lukevat koodia jatkuvasti tehdessään siihen muutoksia Koodin luettavuuden parantaminen nopeuttaa koodin kirjoittamista! Luettavuuden parantaminen voidaan siis tehdä kirjoittamisen kustannuksella. 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 3
Mitä on hyvä koodi? Hyvä ohjelmakoodi? Koodia pystyy lukemaan ymmärrettävinä lauseina Koodi tekee sen, mitä olettaa sen tekevän, eikä mitään muuta. (Koodi ei sisällä yllätyksiä!) Koodi läpäisee kaikki testit, mukaan lukien kääntäjän ja katselmoinnin. Koodi on yhtenäinen muun koodin kanssa. 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 4
Ohjelmointikäytännöt Miten lähdekoodi kirjoitetaan ja jäsennetään luettavaksi: Nimeämiskäytännöt, vertikaalinen ja horisontaalinen muotoilu, sisennykset, koodin kommentointi Virheidenkäsittely, luokkarakenteet ja muut projektin ohjelmointikäytännöt Ohjelmointikäytännön tarkoituksena on: Lähdekoodin yhtenäisyyden säilyttäminen, siten että se on aina luettavaa. Rajoittavat huonojen tapojen käyttöä Lisäävät ennustettavuutta lähdekoodiin. Auttavat ohjelmoijaa keskittymään olennaiseen. Kompensoidaan ohjelmointikielien rajoitteita. 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 5
Ohjelmointikäytännöt Pitää sopia jokaisessa ohjelmistoprojektissa ennen koodauksen aloittamista Jos koodaus on jo ehditty aloittaa, on liian myöhäistä. Kirjataan ylös, jotta voidaan tarkistaa myöhemmin. Käytännöt vaihtelevat: Eri ohjelmointikielien välillä Eri ohjelmoijien välillä Tärkeintä on sopia kulloisessakin projektissa käytettävä käytäntö. Kaikkien pitää noudattaa sovittua käytäntöä! Tarkistus: Muotoilu automatisoidaan IDE:llä Automaattinen tarkistus buildi serverillä Huonolaatuinen koodi == build failed!!! 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 6
Ohjelmointikäytännöt Googlen C/C++ ohjelmointikäytännöt: http://googlestyleguide.googlecode.com/svn/trunk/cppguide.xml 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 7
Koodin asettelu Sisennys: { aaltosulun jälkeen lisää sisennystä } aaltosuluin jälkeen sisennys pois Sisennys = 4 merkkiä (tab) 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 8
Koodin asettelu Vertikaalinen etäisyys: Mitä vähemmän koodia luettaessa täytyy skrollata pystysunnassa sen parempi. Lyhyitä funktiota ei tarvitse skrollata. Muuttujien esittely mahdollisimman lähelle niiden käyttöpaikkaa. Horisontaalinen etäisyys: Sivusuunnassa ei pidä joutua skrollaamaan. ~80-100 merkkiä max. rivinpituus. Käytä välilyöntiä erottimena! for(i=0;i<5;i++) -> for( i = 0; i < 5; i++ ) 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 9
Nimeäminen Hyvät nimet muodostavat 90% ohjelmakoodin luettavuudesta! Käytä nimien miettimiseen aikaa! Nimeä, uudelleennimeä ja vielä kerran uudelleennimeä! Nimet: Kuvaavia! Kertovat kaiken tarpeellisen! Perustuvat sovittuun ohjelmointikäytäntöön! Yksiselitteisiä! 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 10
Nimeäminen Vältä enkoodauksia ja lyhennyksiä! strcbacdata* _ptr_bacdata; WTF??? Nykyaikaiset kääntäjät osaavat selvittää tyypeistä kaiken tarpeellisen, tätä tietoa ei tarvitse kirjata itse ylös. Nimien maksimipituus ei enää ole 8 merkkiä. Valitse aina yksi sana / käsite fetch, get ja retrieve tarkoittavat samaa, mutta sotkevat koodia, jos niitä käytetään ristiin. Käytä nimiä, jotka liittyvät ongelmaan, jota yritetään ratkaista. Jos käsitellään listaa opiskelijoista, kuvaava nimi on silloin esim. students, eikä data. 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 11
Funktiot Hyviä ohjelmointitapoja SRP = Single Responsibility Principle Funktioiden pitää tehdä vain yksi asia! Nimeäminen: Funktion nimen pitäisi kertoa selvästi mitä funktio tekee: do(int *r, int s); calculatecoursegrades(int examresults[], int size); Suosi pientä kokoa: Funktioiden pitäisi olla mahdollisimman pieniä. Parametrien määrä myös on syytä pitää pienenä. Jos joudut kommentoinnilla erottamaan erillisiä osia koodista, tee mieluummin tällöin uusi funktio. Liian pitkä funktio tai pitkä parametrilista kertoo usein sen, että rikotaan SRP sääntöä. 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 12
Funktiot Hyviä ohjelmointitapoja Vältä sivuvaikutuksia: Funktion pitäisi tehdä vain yksi asia, joka pitää käydä selville funktion nimestä. (SRP!) Jos funktio tekee jotain muuta, mikä ei selviä funktion nimestä, on koodia heti vaikeampi ymmärtää. Esim. funktio laskee saamansa taulukon arvoista halutun tuloksen, mutta samalla muuttaa taulukon arvoja. Sivuvaikutuksista johtuvia virheitä on todella vaikea selvitellä. 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 13
Funktiot Hyviä ohjelmointitapoja Älä käytä lippu-parametreja (flags) Eli parametreja joiden perusteella funktion toiminnallisuus muuttuu. Tällöin on vaikea pysyä selvillä mitä funktio milloinkin tekee, koska koodia luettaessa joudutaan myös pitämään mielessä miten parametri vaikuttaa funktion suoritukseen. Esim. void printcheck(int outputtype); => void printcheckxml(); void printcheckplaintext(); 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 14
Koodin kommentointi C-kielessä: // yhden rivin kommentti /* usean rivin kommentti */ 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 15
Koodin kommentointi Kommentteja käytetään usein selittämään huonoa koodia! Kertovat, että koodissa on jotain vikaa, koska sitä täytyy selitellä. Turhat kommentit vaikeuttavat koodin lukemista. Itsestään selvät kommentit int number; // number char studentname[20]; // opiskelijan nimi Asiaankuulumaton tieto: Kuuluu muualle kuin koodin sekaan Versiohistoriaa, muutoshistoriaa, todo-listat Vanhentuneet kommentit Kommentit jotka eivät enää pidä paikkaansa Vaikeuttavat koodin ymmärtämistä! 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 16
Kodin kommentointi Kommenttia kirjoittaessa: Mieti miten korjaat koodin siten, että kommentointi on turhaa. Jos kuitenkin tarvetta kommentoida, kirjoita kommentti huolellisesti! Mitä kielioppivirheet yms hätäiset kommentit kertovat kommentoidun koodin laadusta? Entä kirjoittajasta? Hyödyllisin kommentti kertoo koodista miksi jokin asia on tehty, ei miten. 21/3/11 Ohjelmistotuotanto (Mikko Vuorinen) Metropolia Ammattikorkeakoulu 17
Kysymyksiä? 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 18