Yleisimpiä virheenlajeja ohjelmoinnissa

"Meilkein kaikki noista näkyy jo kääntäjän varoituksissa/virheilmoituksissa eikä niitä virheitä tästä syystä tee oikeasti kukaan järkevä ihminen."

(hah, tuossakin lauseessa on muuten kirjoitusvirhe "Meilkein")

Mitä sitten vaikka kääntäjä kertoisi, on parempi välttää virhe alusta asti. Ja on hyvä luetella virheet keskitetysti yhdessä listassa, vaikka kaikki jollain tavalla tietäisivätkin kaikki listan kohdat. Virhemahdollisuudet tiedostaa paremmin / todennäköisemmin jos ne on saatu yhdestä listasta, ja listan kohtien vertailu ja järjestely on helpompaa / todennäköisempää kuin hajallaan tiedostettujen yksityiskohtien.

Mikä noista virheistä näkyy kaikissa tapauksissa kaikilla mahdollisilla virheentekotavoilla kaikenlaisten lähdekoodien osana, kääntäjän virheilmoituksena?

Lisään listaan:

-for-laskuri saavuttaa lukutyypin ylärajan

-muuttuja menee laskutoimituksessa lukutyypin ylärajan yli.

(silloin ehkä c:ssä long long int on paikallaan... tosiaan 2 long sanaa)

gnoemd kirjoitti:

"Meilkein kaikki noista näkyy jo kääntäjän varoituksissa/virheilmoituksissa eikä niitä virheitä tästä syystä tee oikeasti kukaan järkevä ihminen."

(hah, tuossakin lauseessa on muuten kirjoitusvirhe "Meilkein")

Mitä sitten vaikka kääntäjä kertoisi, on parempi välttää virhe alusta asti. Ja on hyvä luetella virheet keskitetysti yhdessä listassa, vaikka kaikki jollain tavalla tietäisivätkin kaikki listan kohdat. Virhemahdollisuudet tiedostaa paremmin / todennäköisemmin jos ne on saatu yhdestä listasta, ja listan kohtien vertailu ja järjestely on helpompaa / todennäköisempää kuin hajallaan tiedostettujen yksityiskohtien.

Mikä noista virheistä näkyy kaikissa tapauksissa kaikilla mahdollisilla virheentekotavoilla kaikenlaisten lähdekoodien osana, kääntäjän virheilmoituksena?

Lisään listaan:

-for-laskuri saavuttaa lukutyypin ylärajan

-muuttuja menee laskutoimituksessa lukutyypin ylärajan yli.

(silloin ehkä c:ssä long long int on paikallaan... tosiaan 2 long sanaa)

Lue lisää

Kirjoitusvirhe on erityisen haitallinen jos se muuttaa nimen jonkun toisen muuttujan tms. nimeksi. Siksi on syytä välttää pitkiä nimiä, jotka yhden kirjaimen muutoksella tai poisjätöllä muuttuvat joksikin muuksi käytössä olevaksi nimeksi.

Onko ohjelmaa, joka varoittaa jos kahdella muuttujalla on melkein sama nimi, tilanteessa jossa kääntäjä ei antaisi virheilmoitusta sekaannuksen sattuessa?

gnoemd kirjoitti:

"Meilkein kaikki noista näkyy jo kääntäjän varoituksissa/virheilmoituksissa eikä niitä virheitä tästä syystä tee oikeasti kukaan järkevä ihminen."

(hah, tuossakin lauseessa on muuten kirjoitusvirhe "Meilkein")

Mitä sitten vaikka kääntäjä kertoisi, on parempi välttää virhe alusta asti. Ja on hyvä luetella virheet keskitetysti yhdessä listassa, vaikka kaikki jollain tavalla tietäisivätkin kaikki listan kohdat. Virhemahdollisuudet tiedostaa paremmin / todennäköisemmin jos ne on saatu yhdestä listasta, ja listan kohtien vertailu ja järjestely on helpompaa / todennäköisempää kuin hajallaan tiedostettujen yksityiskohtien.

Mikä noista virheistä näkyy kaikissa tapauksissa kaikilla mahdollisilla virheentekotavoilla kaikenlaisten lähdekoodien osana, kääntäjän virheilmoituksena?

Lisään listaan:

-for-laskuri saavuttaa lukutyypin ylärajan

-muuttuja menee laskutoimituksessa lukutyypin ylärajan yli.

(silloin ehkä c:ssä long long int on paikallaan... tosiaan 2 long sanaa)

Lue lisää

Ei varmaan pitäisi vastata tällaiseen viestiin, mutta pointti on, että yleensä ammattiohjelmoija kirjoittaa ohjelmat käyttäen sellaista ohjelmointityyliä, että jos tuollaisia virheitä tulee, ne ihan varmasti näkyvät seuraavassa ohjelman kääntöyrityksessä hyvin selvästi.

"(hah, tuossakin lauseessa on muuten kirjoitusvirhe "Meilkein") "

Olen pahoillani. Jos et ymmärtänyt, niin tarkoitin "melkein".

Käydään nyt vittumaiseen sävyyn kaikki läpi:

"-Merkkikokosekaannus (CaSe)"

Jos tämä tarkoittaa, että kirjoitetaan "for" muodossa "For", niin jos ei syntax highlighting jo paljasta, niin ensimmäinen kääntö. Muuttujissa tulee taas joko "undefined variable" tai "uninitialized variable" riippuen siitä meneekö päällekkäin olemassaolevan kanssa vai ei.

"-pyöreästä liuku-luku-vakiosta jää .0, eli pitää olla 1.0/4.0 eikä 1/4 (eli 1 jaettuna 4). Muuten kääntäjä tulkitsee luvut kokonaislukuina joten tulosten pyöristykset on sen mukaan."

Tästä kääntäjä ei kyllä varoita, mutta niin triviaali virhe, että tuskin kukaan oikeasti tällaista tekee.

"-taulukosta(array), vectorista ym. sekoitetaan koko ja viimeinen indeksi, koska indeksit alkaa nollasta ja koko yhdestä. Ohjelmointi taitaa olla ainoa yhteys missä puhutaan nollannesta kohdasta, joten ei ihme, että siinä tulee helposti virhe."

Noniin just. Ja joskus laitetaan kengät vahingossa vääriin jalkoihin kun niitä on niin vaikea erottaa. Ei tällaista virhettä kukaan oikeasti tee jos on edes muutaman vuoden ohjelmoinut!

"-c:n if tai while lausekkeessa = eikä ==. Yksi = merkki katsoo vain sijoituksen onnistumista joten se kääntyy ja voi toimiakin, joten virhettä on vaikeampi havaita kuin edellisiä virheitä. Eli = on sijoitusoperaattori ja == vertailuoperaattori."

Kääntäjä varoittaa kyllä tästä: "warning: suggest parentheses around assignment used as truth value". Eli ei mene läpi ilman kääntäjän varoituksia.

"-c:n kerto/osoitin merkin eli * sekaannus."

No joojoo. osoitinmerkki on unaarinen operaattori ja kertomerkki on binäärinen. Aika hyvin saa kämmätä että näitä käyttää väärin. Tietty jollain pointteriaritmetiikalla voi saada aikaa vaikka mitä, mutta sellaista ei kukaan ammattiohjelmoija käytä.

"-Muuttujan nollaus tai säilön tyhjennys silmukan alussa jää. Seuraus voi olla mm. oudon suuri muistinkulutus."

Yleisesti ottaen tähän ei ole mitään lääkettä, mutta yleensä ohjelmointityyli pidetään sellaisena, että nämä vältetään. Myös käyttämällä iteraattoreita tai lokaaleja laskureita tätä ongelmaa ei tule. Muistinkulutukseen tämä ei kyllä suoraan liity.

"-joskus pitää olla unsigned char eikä char. Ainakin c :n otto-operaattorilla " > > " binääritiedostoa luettaessa."

Jos lukee "> >"-operaattorilla suoraan (unsigned) char-muuttujaan binääritiedostoa, voi odottaakin ongelmia. Tämän yrittäminen on bugi jo sinänsä ja se on vältettävissä käyttämällä jotain muuta tapaa.

"-loppumerkki tekstitiedoston ja c-merkkijonon päässä voi aiheuttaa sekaannuksia."

En ymmärrä mihin tässä viitataan.

"-voin arvata, että joku 64-bittiselle koneelle kirjoitettu 32 bittisessä ja päinvastoin, aiheuttaa kääntövirheitä ja outoa toimintaa."

Tiedätkö edes mitä tarkoittaa se, että kone on 64- tai 32-bittinen? Miten tämä vaikuttaa kääntämisen onnistumiseen, jos kääntäjä on sama? Vastaava ongelma on kyllä oikeasti sulautetuissa järjestelmissä, mutta ongelma on hieman syvällisempi.

"Lisään listaan:"

"-for-laskuri saavuttaa lukutyypin ylärajan"

Tämä on kyllä teoriassa mahdollinen, mutta kääntäjä varoittaa kyllä ylärajan ehdon tarkistamisesta, jos siinä on riski ylivuotoon. Yleisimmillä ohjelmointityyleillä tätä ei voi edes tapahtua.

"-muuttuja menee laskutoimituksessa lukutyypin ylärajan yli. "

Ihan mahdollista, eikä täysin koskaan vältettävissä. Mutta kääntäjä osaa varoittaa yllättävän monista riskipaikoista.

qweqweqweqw kirjoitti:

Ei varmaan pitäisi vastata tällaiseen viestiin, mutta pointti on, että yleensä ammattiohjelmoija kirjoittaa ohjelmat käyttäen sellaista ohjelmointityyliä, että jos tuollaisia virheitä tulee, ne ihan varmasti näkyvät seuraavassa ohjelman kääntöyrityksessä hyvin selvästi.

"(hah, tuossakin lauseessa on muuten kirjoitusvirhe "Meilkein") "

Olen pahoillani. Jos et ymmärtänyt, niin tarkoitin "melkein".

Käydään nyt vittumaiseen sävyyn kaikki läpi:

"-Merkkikokosekaannus (CaSe)"

Jos tämä tarkoittaa, että kirjoitetaan "for" muodossa "For", niin jos ei syntax highlighting jo paljasta, niin ensimmäinen kääntö. Muuttujissa tulee taas joko "undefined variable" tai "uninitialized variable" riippuen siitä meneekö päällekkäin olemassaolevan kanssa vai ei.

"-pyöreästä liuku-luku-vakiosta jää .0, eli pitää olla 1.0/4.0 eikä 1/4 (eli 1 jaettuna 4). Muuten kääntäjä tulkitsee luvut kokonaislukuina joten tulosten pyöristykset on sen mukaan."

Tästä kääntäjä ei kyllä varoita, mutta niin triviaali virhe, että tuskin kukaan oikeasti tällaista tekee.

"-taulukosta(array), vectorista ym. sekoitetaan koko ja viimeinen indeksi, koska indeksit alkaa nollasta ja koko yhdestä. Ohjelmointi taitaa olla ainoa yhteys missä puhutaan nollannesta kohdasta, joten ei ihme, että siinä tulee helposti virhe."

Noniin just. Ja joskus laitetaan kengät vahingossa vääriin jalkoihin kun niitä on niin vaikea erottaa. Ei tällaista virhettä kukaan oikeasti tee jos on edes muutaman vuoden ohjelmoinut!

"-c:n if tai while lausekkeessa = eikä ==. Yksi = merkki katsoo vain sijoituksen onnistumista joten se kääntyy ja voi toimiakin, joten virhettä on vaikeampi havaita kuin edellisiä virheitä. Eli = on sijoitusoperaattori ja == vertailuoperaattori."

Kääntäjä varoittaa kyllä tästä: "warning: suggest parentheses around assignment used as truth value". Eli ei mene läpi ilman kääntäjän varoituksia.

"-c:n kerto/osoitin merkin eli * sekaannus."

No joojoo. osoitinmerkki on unaarinen operaattori ja kertomerkki on binäärinen. Aika hyvin saa kämmätä että näitä käyttää väärin. Tietty jollain pointteriaritmetiikalla voi saada aikaa vaikka mitä, mutta sellaista ei kukaan ammattiohjelmoija käytä.

"-Muuttujan nollaus tai säilön tyhjennys silmukan alussa jää. Seuraus voi olla mm. oudon suuri muistinkulutus."

Yleisesti ottaen tähän ei ole mitään lääkettä, mutta yleensä ohjelmointityyli pidetään sellaisena, että nämä vältetään. Myös käyttämällä iteraattoreita tai lokaaleja laskureita tätä ongelmaa ei tule. Muistinkulutukseen tämä ei kyllä suoraan liity.

"-joskus pitää olla unsigned char eikä char. Ainakin c :n otto-operaattorilla " > > " binääritiedostoa luettaessa."

Jos lukee "> >"-operaattorilla suoraan (unsigned) char-muuttujaan binääritiedostoa, voi odottaakin ongelmia. Tämän yrittäminen on bugi jo sinänsä ja se on vältettävissä käyttämällä jotain muuta tapaa.

"-loppumerkki tekstitiedoston ja c-merkkijonon päässä voi aiheuttaa sekaannuksia."

En ymmärrä mihin tässä viitataan.

"-voin arvata, että joku 64-bittiselle koneelle kirjoitettu 32 bittisessä ja päinvastoin, aiheuttaa kääntövirheitä ja outoa toimintaa."

Tiedätkö edes mitä tarkoittaa se, että kone on 64- tai 32-bittinen? Miten tämä vaikuttaa kääntämisen onnistumiseen, jos kääntäjä on sama? Vastaava ongelma on kyllä oikeasti sulautetuissa järjestelmissä, mutta ongelma on hieman syvällisempi.

"Lisään listaan:"

"-for-laskuri saavuttaa lukutyypin ylärajan"

Tämä on kyllä teoriassa mahdollinen, mutta kääntäjä varoittaa kyllä ylärajan ehdon tarkistamisesta, jos siinä on riski ylivuotoon. Yleisimmillä ohjelmointityyleillä tätä ei voi edes tapahtua.

"-muuttuja menee laskutoimituksessa lukutyypin ylärajan yli. "

Ihan mahdollista, eikä täysin koskaan vältettävissä. Mutta kääntäjä osaa varoittaa yllättävän monista riskipaikoista.

Lue lisää

Tätä on kirjoitettu c mielessä, mutta tässä on paljon kieliriippumatonta. Muiden kielien käyttäjät saavat vapaasti kommentoida miten mahdotonta se ja se virhe on heidän käyttämässään kielessä, jos aihetta on.

1.Jos käyttää c:n union-rakennetta, ja sijoittaa datan tyyppinä char k[4] ja ottaa sen long int muodossa, 64 bittisellä se pitäisi olla k[8] eli 8 tavun eli 64 bitin data 32 bitin eli 4 tavun sijaan.

2.Säilön puhdistamattomuus silmukassa voi kavalasti tuhlata muistia jos sitä täytetään välistä ja luetaan vain täyttökohdan läheltä. Takaa täyttäessä myös toiminnallisuus on väärin.

3."Jos lukee "> >"-operaattorilla suoraan (unsigned) char-muuttujaan binääritiedostoa, voi odottaakin ongelmia. Tämän yrittäminen on bugi jo sinänsä ja se on vältettävissä käyttämällä jotain muuta tapaa."

Mitä ongelmia? Vain siitä etumerkistä on tullut ihmeteltävää. Mikä muu tapa?

4.Loppumerkki sekoittaa c-merkkijonon tai tekstitiedoston pituuskäsitystä.

5.MerkkiKoossa suurin ongelma on YhdysSanojen erilaiset kirjoitus_tavat.

6.Jos kirjoitusvirhe johtaa esim. siihen, että laskentakaavassa / yhtälössä johonkin kohtaa tulee väärä muuttuja, niin sitä bugia saattaa olla vaikea havaita ja löytää.

7."-pyöreästä liuku-luku-vakiosta jää .0, eli pitää olla 1.0/4.0 eikä 1/4 (eli 1 jaettuna 4). Muuten kääntäjä tulkitsee luvut kokonaislukuina joten tulosten pyöristykset on sen mukaan."

Tästä kääntäjä ei kyllä varoita, mutta niin triviaali virhe, että tuskin kukaan oikeasti tällaista tekee.

kyllä tekee

8."-taulukosta(array), vectorista ym. sekoitetaan koko ja viimeinen indeksi, koska indeksit alkaa nollasta ja koko yhdestä. Ohjelmointi taitaa olla ainoa yhteys missä puhutaan nollannesta kohdasta, joten ei ihme, että siinä tulee helposti virhe."

Noniin just. Ja joskus laitetaan kengät vahingossa vääriin jalkoihin kun niitä on niin vaikea erottaa. Ei tällaista virhettä kukaan oikeasti tee jos on edes muutaman vuoden ohjelmoinut!

kyllä tekee

ja:

En tiedä onko tätä yritetty tilastoida, mutta saattaa olla että suurin osa ohjelmointityökaluja ohjelmointiin käyttävistä on amatöörejä, harrastelijoita tai silloin tällöin jotain laskentaongelmaa omalla ohjelmalla ratkovia(eli ohjelmointityökaluilla halutaan ensisijaisesti saada laskennan tulos - ei ohjelmaa). Siksi on tärkeää listata ja tiedostaa alkeellisetkin virheen lajit.

gdfnrjnqwv kirjoitti:

Tätä on kirjoitettu c mielessä, mutta tässä on paljon kieliriippumatonta. Muiden kielien käyttäjät saavat vapaasti kommentoida miten mahdotonta se ja se virhe on heidän käyttämässään kielessä, jos aihetta on.

1.Jos käyttää c:n union-rakennetta, ja sijoittaa datan tyyppinä char k[4] ja ottaa sen long int muodossa, 64 bittisellä se pitäisi olla k[8] eli 8 tavun eli 64 bitin data 32 bitin eli 4 tavun sijaan.

2.Säilön puhdistamattomuus silmukassa voi kavalasti tuhlata muistia jos sitä täytetään välistä ja luetaan vain täyttökohdan läheltä. Takaa täyttäessä myös toiminnallisuus on väärin.

3."Jos lukee "> >"-operaattorilla suoraan (unsigned) char-muuttujaan binääritiedostoa, voi odottaakin ongelmia. Tämän yrittäminen on bugi jo sinänsä ja se on vältettävissä käyttämällä jotain muuta tapaa."

Mitä ongelmia? Vain siitä etumerkistä on tullut ihmeteltävää. Mikä muu tapa?

4.Loppumerkki sekoittaa c-merkkijonon tai tekstitiedoston pituuskäsitystä.

5.MerkkiKoossa suurin ongelma on YhdysSanojen erilaiset kirjoitus_tavat.

6.Jos kirjoitusvirhe johtaa esim. siihen, että laskentakaavassa / yhtälössä johonkin kohtaa tulee väärä muuttuja, niin sitä bugia saattaa olla vaikea havaita ja löytää.

7."-pyöreästä liuku-luku-vakiosta jää .0, eli pitää olla 1.0/4.0 eikä 1/4 (eli 1 jaettuna 4). Muuten kääntäjä tulkitsee luvut kokonaislukuina joten tulosten pyöristykset on sen mukaan."

Tästä kääntäjä ei kyllä varoita, mutta niin triviaali virhe, että tuskin kukaan oikeasti tällaista tekee.

kyllä tekee

8."-taulukosta(array), vectorista ym. sekoitetaan koko ja viimeinen indeksi, koska indeksit alkaa nollasta ja koko yhdestä. Ohjelmointi taitaa olla ainoa yhteys missä puhutaan nollannesta kohdasta, joten ei ihme, että siinä tulee helposti virhe."

Noniin just. Ja joskus laitetaan kengät vahingossa vääriin jalkoihin kun niitä on niin vaikea erottaa. Ei tällaista virhettä kukaan oikeasti tee jos on edes muutaman vuoden ohjelmoinut!

kyllä tekee

ja:

En tiedä onko tätä yritetty tilastoida, mutta saattaa olla että suurin osa ohjelmointityökaluja ohjelmointiin käyttävistä on amatöörejä, harrastelijoita tai silloin tällöin jotain laskentaongelmaa omalla ohjelmalla ratkovia(eli ohjelmointityökaluilla halutaan ensisijaisesti saada laskennan tulos - ei ohjelmaa). Siksi on tärkeää listata ja tiedostaa alkeellisetkin virheen lajit.

Lue lisää

2.Säilön puhdistamattomuus silmukassa voi kavalasti tuhlata muistia jos sitä täytetään välistä ja luetaan vain täyttökohdan läheltä. Takaa täyttäessä myös toiminnallisuus on väärin.

Tämä siis luultavasti vain jos säilöön sijoitetaan säilöjä. Jos on vaikka vectori string ejä täynnä.

tai:
list( list( float ) ) ListojenLista;

Suurempi kuin ja pienempi kuin merkit on korvattu suluilla koska Suomi24 ei aina toista niitä oikein.

Pointterivirheet
1. Tähtien määrä tai alustus väärin/puuttuu: *p, **p, ****p
Itse muistan vain kerran koodissa 3 tähden pointerin (funktion parametrina).
2. Pointerin castausvirhe tai puutos pointerin siirrossa esim *((int)*(p 1)))
Muistivirheet
3. malloc ja free ei esim vapauta muistia kaikissa virhetilannehaaroissa