Ohjelmointikäytännöt
Ohjelmointikäytännöt ovat joukko ohjeita, joilla voidaan määrittää ohjelmistotuotantoprosessissa käytetyt menetelmät ja tuotetun lähdekoodin ulkoasu sekä rakenne. Pyrkimyksenä on tuottaa luettavampaa, virheettömämpää ja helpommin ylläpidettävää ohjelmakoodia. Ohjelmointikäytännöillä ei ole vaikutusta käännettyyn binääriin, vaan ne ovat olemassa ihmistä varten. Ohjelmointikäytännöiksi voidaan lukea esimerkiksi säännöt tiedostorakenteesta, ohjelmointiympäristöstä, nimeämisestä, sisentämisestä, kommentoinnista jne.
Etuja[muokkaa | muokkaa wikitekstiä]
Ylläpidettävyys[muokkaa | muokkaa wikitekstiä]
Tutkimusten mukaan tyypillisen ohjelmistoprojektin elinkaaresta 80 % kuluu ohjelmiston ylläpitoon.lähde? Tästä ajasta 50–60 % menee koodin lukemiseen ja ymmärtämiseen.lähde? Ohjelmointikäytäntöjen avulla voidaan selkeyttää koodin rakennetta ja parantaa luettavuutta. Näin ollen ohjelmiston ylläpito helpottuu ja tulee ylipäätään mielekkääksi ja mahdolliseksi.
Laatu[muokkaa | muokkaa wikitekstiä]
Tilastollisesti ohjelmistoissa esiintyy tietyntyyppisiä virheitä useammin kuin muita virheitä. Myös yksilöllisesti tietyillä ohjelmoijilla on tapana toistaa tietyn tyyppisiä virheitä. Ohjelmointikäytännöillä voidaan suojautua tällaisia virheitä vastaan. Säännöillä voidaan esimerkiksi rajoittaa globaalien muuttujien käyttöä tai vaatia osoittimien nollaamista käytön jälkeen.
Koodin katselmointi on tehokas tapa parantaa ohjelmiston laatua. Jos kaikki projektin jäsenet toimivat samojen käytäntöjen mukaisesti, on katselmoijien helpompi lukea koodia, helpompi tehdä oletuksia koodista ja helpompi löytää virheitä.[1]
Ennustettavuus[muokkaa | muokkaa wikitekstiä]
Vakiintunut käytäntö ohjelmistorakenteen ja tiettyjen menetelmien, kuten virheenkäsittelyn suhteen auttaa ohjelmoijia tekemään enemmän oletuksia koodista. Jo pelkästään tiedostorakennetta katsomalla he voivat nähdä mistä löytyy heidän etsimänsä koodinpätkä ja itse koodinpätkää lukemalla he voivat olettaa miten se toimii alemmalla tasolla. Jos esimerkiksi virheiden käsittelyyn, syötteiden lukemiseen ja luokkien rajapintoihin on yhteinen käytäntö, se luo koodille loogisen rakenteen, jota muiden ohjelmoijien on helppo seurata. Ilman vakiintunutta käytäntöä se on tehtävä lukemalla ohjelmaa järjestelmällisesti läpi.
Automatisointi[muokkaa | muokkaa wikitekstiä]
Ohjelmointikäytännöt eivät tee ohjelmoinnista hitaampaa. Se tekee siitä nopeampaa. Ohjelmoinnissa useimmat asiat voi tehdä monella vapaavalintaisella tavalla. Jos näihin vapaavalintaisiin tapoihin on vakiintunut käytäntö, niin samaa valintaa ei tarvitse tehdä joka kerta uudestaan. Lisäksi muut samaa käytäntöä noudattavat ohjelmoijat tietävät heti mistä on kysymys.
Joidenkin käytäntöjen avulla monet tehtävät voidaan automatisoida kokonaan. Esimerkiksi ohjelmiston dokumentointi voidaan automatisoida käyttämällä Javadocin tai Doxygenin tunnistamaa ohjelmointityyliä.
Ohjelmointikielten puutteet[muokkaa | muokkaa wikitekstiä]
Ohjelmointikäytännöillä voidaan kompensoida ohjelmointikielessä esiintyviä puutteita ja suojautua mahdollisesti vaarallisia kohtia vastaan. Esimerkiksi nimeämiskäytännöillä voidaan korvata Pythonista puuttuvat vakiot. Yksinkertaisella nimeämissäännöllä voidaan koodin lukijalle kertoa onko muuttujaa tarkoitus kirjoittaa, lukea vai sekä että.
Kritiikkiä[muokkaa | muokkaa wikitekstiä]
Ohjelmointikäytäntöjä on yleisellä tasolla kritisoitu varsin vähän. Tyypillisesti kritiikki kohdistuu yksittäisiin käytäntöihin, jotka voivat olla huonosti määriteltyjä tai projektiin sopimattomia. Yleisellä tasolla ohjelmointikäytäntöjen on kritisoitu hidastavan ohjelmointia lähinnä kahdesta syystä.
Ensimmäinen syy koskee hyvin pieniä projekteja, joissa ohjelmointikäytäntöjen opettelu tuo ylimääräisen vaiheen projektin alkuun, eikä käytäntöjen tuoma hyöty pääse koskaan esille. Sasa M. Deklevan tutkimuksen mukaan hyvien ohjelmointikäytäntöjen mukaan kirjoitettuun koodiin todella käytetään enemmän aikaa kuin ilman sääntöjä kirjoitettuun koodiin. Syy tosin on siinä, että ilman sääntöjä kirjoitettu koodi kirjoitetaan tyypillisesti kerran ja heitetään sen jälkeen romukoppaan. Sääntöjen mukaan kirjoitettu koodi puolestaan käytetään uudestaan ja mahdollisesti laajennetaan tai muokataan useampiin tarkoituksiin soveltuvaksi. Tämä pätee myös ohjelmoijan omaan käyttöön kirjoittamalleen koodille. Toinen kritiikkiä vastaan puhuva asia on, että luettavan koodin kirjoittaminen kehittää ohjelmoijalle rutiinin kirjoittaa luettavaa koodia projektin koosta riippumatta.[1][2]
Toinen kritiikin syy koskee puolestaan tyypillisesti suurempia projekteja. Projektin koon ollessa hyvin suuri se näkyy usein lisääntyneinä sääntöinä, joita projektin jäsenet joutuvat opettelemaan. Vaarana on että säännöistä tulee ristiriitaisia ja että niitä tulee liikaa opeteltavaksi. Huoli on aiheellinen jos ohjelmointikäytäntöjen määrä ja laatu ei pysy hallinnassa. Vaikka ohjelmointikäytännöt ovatkin hyvä asia, on niissäkin liiallisuuksiin meneminen pahasta.[1]
Esimerkkejä[muokkaa | muokkaa wikitekstiä]
 |
Tämän artikkelin tai sen osan muoto tai tyyli kaipaa korjausta. Voit auttaa Wikipediaa parantamalla artikkelia. Lisää tietoa saattaa olla keskustelusivulla. Tarkennus: lähdeviitteiden muotoilu mallineilla |
Nimeämiskäytännöt[muokkaa | muokkaa wikitekstiä]
Java-kielen nimeämiskäytäntöjä ovat ehdottaneet ja vakiinnuttaneet useat Java-yhteisöt kuten Sun Microsystems[3], Netscape[4], AmbySoft[5] jne.
Esimerkki Sun Microsystemsin nimeämiskäytännöistä:
| Tyyppi | Nimeämissäännöt | Esimerkkejä |
|---|---|---|
| Luokat | Luokkien nimien tulisi olla substantiiveja ja aloitettu isolla alkukirjaimella. Jos luokan nimi koostuu useammasta sanasta, jokainen sana aloitetaan isolla kirjaimella. Luokkien nimien tulisi olla yksinkertaisia ja kuvaavia. Lyhenteitä tulisi välttää, ellei lyhenne ole tunnetumpi, kuin pitkä muoto (esim. URL ja HTML). | class Class;
class MyClass; |
| Metodit | Metodien nimien tulisi ilmaista tekemistä siten, että useampisanaisissa metodeissa ensimmäinen sana aloitetaan pienellä alkukirjaimella ja muut isolla. | run();
runFast(); getBackground(); |
| Muuttujat | Muuttujien nimien tulee alkaa pienellä kirjaimella. Muuttujien nimien aloittamista _- tai $- merkillä vältetään, vaikka molemmat sallitaankin syntaksissa.
Lisäksi muuttujien nimien tulee olla lyhyitä ja kuvaavia (muuttujan nimen pitäisi pystyä toimimaan muistitukena ohjelmoijalle). Yhden merkin pituisia muuttujien nimiä tulisi välttää, ellei kyseessä ole väliaikaismuuttuja. Kirjaimia i, j, k, m, ja n käytetään tyypillisesti kokonaisluvuille ja kirjaimia c, d, ja e merkeille. |
int i;
char c; float myWidth; |
Symbian-alustalla oli useita eri luokkien nimeämisiä niiden käyttötapojen mukaan.[6] Luokan etuliitteenä oli T, S, C, R, M tai N -kirjain.[6]
Linux-ytimen ohjelmointioppaassa suositellaan Kerninghan&Ritchie (K&R C)-tyyliä: tyyli poikkeaa GNU-projektin käytännöistä sekä Unkarilaisesta notaatiosta.[7][8]
Kontrollirakenteet[muokkaa | muokkaa wikitekstiä]
Loogisten kontrollirakenteiden oikeanlainen käyttö helpottaa koodin tulkitsemista. Esimerkki pseudo-koodina:
i = 0 while i < 5 print i * 2 i = i + 1 end while print "Ended loop"
Yllä oleva koodinpätkä noudattaa nimeämis- ja sisennyskäytäntöjä, mutta seuraavassa esimerkissä käytetty for-rakenteen käyttö tekee koodista helpommin luettavan:
for i = 0, i < 5, i=i+1 print i * 2 print "Ended loop"
Aaltosulkeita hyödyntävissä ohjelmointikielissä yleinen tyyli on käyttää sulkeita kontrollirakenteiden yhteydessä silloinkin, kun niiden käyttö on syntaksin kannalta samantekevää.
for (i = 0 to 5) {
print i * 2;
}
print "Ended loop";
Tällä pyritään estämään bugeja, joiden jäljittäminen voi olla aikaavievää, kuten puolipisteeseen päättyvä kontrollirakenteen käyttö, joka on tyypillinen virhe:
for (i = 0; i < 5; ++i);
printf("%d\n", i*2); /* Sisennys antaa helposti väärän kuvan siitä, että rivi kuuluu silmukan sisään. */
printf("Ended loop");
...tai tilanteita jolloin silmukkaan lisätään jälkeenpäin uusi rivi:
for (i = 0; i < 5; ++i)
fprintf(logfile, "loop reached %d\n", i);
printf("%d\n", i*2); /* Sisennys antaa helposti väärän kuvan siitä, että rivi kuuluu silmukan sisään. */
printf("Ended loop");
Lähteet[muokkaa | muokkaa wikitekstiä]
- ↑ a b c McConnell Steve: Code Complete, 2nd edition
- ↑ Glass Robert L.: Facts and Fallacies of Software Engineering
- ↑ "Code Conventions for the Java Programming Language", Section 9: "Naming Conventions"
- ↑ "NETSCAPE'S SOFTWARE CODING STANDARDS GUIDE FOR JAVA",Collab Software Coding Standards Guide for Java (Arkistoitu – Internet Archive)
- ↑ "AmbySoft Inc. Coding Standards for Java v17.01d", [1]
- ↑ a b Naming Conventions flylib.com. Viitattu 9.2.2020. (englanniksi)
- ↑ Linux kernel coding style kernel.org. ”First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.” Viitattu 9.2.2020. (englanniksi)
- ↑ Linux kernel coding style kernel.org. ”Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer” Viitattu 4.11.2017. (englanniksi)
Aiheesta muualla[muokkaa | muokkaa wikitekstiä]
Ohjelmointikielikohtaisia käytäntöjä[muokkaa | muokkaa wikitekstiä]
- Ada: Ada 95 Quality and Style Guide: Guidelines for Professional Programmers (englanniksi)
- C: Micrium C Coding Standard (Arkistoitu – Internet Archive) (englanniksi)
- C++: Quantum Leaps C/C++ Coding Standard (englanniksi)
- Erlang: Erlang Programming Rules and Conventions (Arkistoitu – Internet Archive) (englanniksi)
- Java: Code Conventions for the Java Programming Language (englanniksi)
- Lisp: Riastradh's Lisp Style Rules (englanniksi)
- Perl: Perl Style Guide (englanniksi)
- PHP::PEAR: PHP::PEAR Coding Standards (englanniksi)
- Python: Style Guide for Python Code (englanniksi)
- Ruby: Good API Design[vanhentunut linkki] (englanniksi)