Linux kernel täyttä kuraa

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

goto on kadotus kirjoitti:

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

Lue lisää

Halle lujaa!

goto on kadotus kirjoitti:

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

Lue lisää

Jep goto on kielletty käsky 99 % ohjelmista!

Eli nyrkkisääntönä voi pitää että
"Pitää tehdä ensin 99 muuta ohjelmaa jonka jälkeen saa käyttää yhdessä ohjelmassa gotoa ja sen jälkeen taas 99 muuta ohjelmaa"

goto on kadotus kirjoitti:

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

Lue lisää

"Ei gotoa voi käyttää oikein! Ei voi!"

Tottakai voi. C-kielestä kun puuttuu poikkeukset.

"Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike."

Eli ei saisi käyttää sitten myöskään setjmp/longjmp kutsujakaan.

Miten sitten toteuttaisit try...catch...finally rakenteen C:llä?

M-Kar kirjoitti:

"Ei gotoa voi käyttää oikein! Ei voi!"

Tottakai voi. C-kielestä kun puuttuu poikkeukset.

"Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike."

Eli ei saisi käyttää sitten myöskään setjmp/longjmp kutsujakaan.

Miten sitten toteuttaisit try...catch...finally rakenteen C:llä?

Lue lisää

"Miten sitten toteuttaisit try...catch...finally rakenteen C:llä? "

Lisäämällä post-inkrementaalioperaation C-kirjaimen perään.

M-Kar kirjoitti:

"Ei gotoa voi käyttää oikein! Ei voi!"

Tottakai voi. C-kielestä kun puuttuu poikkeukset.

"Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike."

Eli ei saisi käyttää sitten myöskään setjmp/longjmp kutsujakaan.

Miten sitten toteuttaisit try...catch...finally rakenteen C:llä?

Lue lisää

Tuossa esimerkki goto käytöstä "oikein" :)

https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/

goto on kadotus kirjoitti:

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

Lue lisää

"Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja..."

Siinä taas oikein malliesimerkki täydellisestä ymmärtämättömyydestä.

Voisin postata tänne esimerkiksi Delphillä koodatun funktion.

Ensimmäisessä versiossa oli yli 10 goto -käskyä.

Koska goto -käskyn *tarpeeton* käyttö todellakin on vain huonoa ohjelmointityyliä / kontrollirakenteiden ymmärtämättömyyttä, niin muokkasin koodia, ja korvasin tarpeettomat goto:t objectpascalin muilla kontrollirakeinteilla kuten while ... do begin ... end sekä repeat ... until.

Näin sain pudotettua goto:jen määrän yli 10:stä kahteen.

Mutta saat olla aika guru, jos koodin toiminnallisuutta muuttamatta pystyy siitä nuo loputkin goto:t poistamaan.

Mahdollisesti voisi yrittää hyödyntää Delphin Break tai Continue -lauseita.

Mutta loppujen kahden goto:n poistaminen koodin toiminnallisuutta muuttamatta on vähintään erittäin vaikeaa, ehkä mahdotonta.

Tästä syystä muuten ko. Delphi -proseduurin konvertointi Javalle saattaa olla mahdotonta, Javassa kun tuota goto:a ei ole lainkaan!

On siis mahdollista tehdä algoritmi, jonka käytännön toteutus onnistuu Delphillä, mutta ei Javalla, juurikin siksi, että Javasta puuttuu goto -käsky.

Haluaako joku ottaa haasteen vastaan, ja yrittää muokata tusta Delphi -koodista loputkin goto:t pois, ja siis vaatimuksena on tietenkin, ettei koodin toiminnallisuus saa muuttua millään tavalla.

eli siis, jos löytyy yksikin syötemerkkijono, jonka tuottama tulosmerkkijono on erilainen goto:llisessa ja goto:ttomassa koodissa, niin se tarkoittaa sitä, että tuossa goto:ttomassa versiossa on toiminnallisuutta muutettu, eli ko. muunnos on väärin tehty.

tässä nyt malliksi funktion otsikkorivi, C -koodaajat kai kutsuisivat sitä nimellä prototyyppi:

function muunna(S:String):String;

Haluaako joku ottaa haasteen vastaan?

Koodi on vuosia sitten tehty, joten jo koodinpätkän etsiminen kiintolevyltäni tulee sekin viemään aikaa...

Delphikoodaaja kirjoitti:

"Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja..."

Siinä taas oikein malliesimerkki täydellisestä ymmärtämättömyydestä.

Voisin postata tänne esimerkiksi Delphillä koodatun funktion.

Ensimmäisessä versiossa oli yli 10 goto -käskyä.

Koska goto -käskyn *tarpeeton* käyttö todellakin on vain huonoa ohjelmointityyliä / kontrollirakenteiden ymmärtämättömyyttä, niin muokkasin koodia, ja korvasin tarpeettomat goto:t objectpascalin muilla kontrollirakeinteilla kuten while ... do begin ... end sekä repeat ... until.

Näin sain pudotettua goto:jen määrän yli 10:stä kahteen.

Mutta saat olla aika guru, jos koodin toiminnallisuutta muuttamatta pystyy siitä nuo loputkin goto:t poistamaan.

Mahdollisesti voisi yrittää hyödyntää Delphin Break tai Continue -lauseita.

Mutta loppujen kahden goto:n poistaminen koodin toiminnallisuutta muuttamatta on vähintään erittäin vaikeaa, ehkä mahdotonta.

Tästä syystä muuten ko. Delphi -proseduurin konvertointi Javalle saattaa olla mahdotonta, Javassa kun tuota goto:a ei ole lainkaan!

On siis mahdollista tehdä algoritmi, jonka käytännön toteutus onnistuu Delphillä, mutta ei Javalla, juurikin siksi, että Javasta puuttuu goto -käsky.

Haluaako joku ottaa haasteen vastaan, ja yrittää muokata tusta Delphi -koodista loputkin goto:t pois, ja siis vaatimuksena on tietenkin, ettei koodin toiminnallisuus saa muuttua millään tavalla.

eli siis, jos löytyy yksikin syötemerkkijono, jonka tuottama tulosmerkkijono on erilainen goto:llisessa ja goto:ttomassa koodissa, niin se tarkoittaa sitä, että tuossa goto:ttomassa versiossa on toiminnallisuutta muutettu, eli ko. muunnos on väärin tehty.

tässä nyt malliksi funktion otsikkorivi, C -koodaajat kai kutsuisivat sitä nimellä prototyyppi:

function muunna(S:String):String;

Haluaako joku ottaa haasteen vastaan?

Koodi on vuosia sitten tehty, joten jo koodinpätkän etsiminen kiintolevyltäni tulee sekin viemään aikaa...

Lue lisää

Millainen testikeissi siinä olisi? Voisin aikani kuluksi miettiä.

Delphikoodaaja kirjoitti:

"Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja..."

Siinä taas oikein malliesimerkki täydellisestä ymmärtämättömyydestä.

Voisin postata tänne esimerkiksi Delphillä koodatun funktion.

Ensimmäisessä versiossa oli yli 10 goto -käskyä.

Koska goto -käskyn *tarpeeton* käyttö todellakin on vain huonoa ohjelmointityyliä / kontrollirakenteiden ymmärtämättömyyttä, niin muokkasin koodia, ja korvasin tarpeettomat goto:t objectpascalin muilla kontrollirakeinteilla kuten while ... do begin ... end sekä repeat ... until.

Näin sain pudotettua goto:jen määrän yli 10:stä kahteen.

Mutta saat olla aika guru, jos koodin toiminnallisuutta muuttamatta pystyy siitä nuo loputkin goto:t poistamaan.

Mahdollisesti voisi yrittää hyödyntää Delphin Break tai Continue -lauseita.

Mutta loppujen kahden goto:n poistaminen koodin toiminnallisuutta muuttamatta on vähintään erittäin vaikeaa, ehkä mahdotonta.

Tästä syystä muuten ko. Delphi -proseduurin konvertointi Javalle saattaa olla mahdotonta, Javassa kun tuota goto:a ei ole lainkaan!

On siis mahdollista tehdä algoritmi, jonka käytännön toteutus onnistuu Delphillä, mutta ei Javalla, juurikin siksi, että Javasta puuttuu goto -käsky.

Haluaako joku ottaa haasteen vastaan, ja yrittää muokata tusta Delphi -koodista loputkin goto:t pois, ja siis vaatimuksena on tietenkin, ettei koodin toiminnallisuus saa muuttua millään tavalla.

eli siis, jos löytyy yksikin syötemerkkijono, jonka tuottama tulosmerkkijono on erilainen goto:llisessa ja goto:ttomassa koodissa, niin se tarkoittaa sitä, että tuossa goto:ttomassa versiossa on toiminnallisuutta muutettu, eli ko. muunnos on väärin tehty.

tässä nyt malliksi funktion otsikkorivi, C -koodaajat kai kutsuisivat sitä nimellä prototyyppi:

function muunna(S:String):String;

Haluaako joku ottaa haasteen vastaan?

Koodi on vuosia sitten tehty, joten jo koodinpätkän etsiminen kiintolevyltäni tulee sekin viemään aikaa...

Lue lisää

Nyt puhut huuhaata. Java on turing täydellinen, sillä toteuttaa ihan kaikki algoritmit.

goto on kadotus kirjoitti:

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

Lue lisää

Mitenkäs meinasit koodata sitten ei ehdolliset hypyt? Keskeytysvektorit on monissa järjestelmissä juurikin goto:ja eli jmp/branch unconditional käskyjä..

goto on kadotus kirjoitti:

Ei gotoa voi käyttää oikein! Ei voi! Sen käyttö on aina merkki ohjelmoijan kelvottomuudesta ja tällainen koodari joutaa palaa helvetin tulessa maailmankaikkeuden loppuun asti! Goton voi aina ohittaa jollain muulla lauserakenteella! Ei ole ainuttakaan järkisyytä käyttää gotoa yhtään missään tilanteessa milloinkan ikinä koskaan! Koko goto on niin saatanasta, että pitäisi itseasiassa kieltää koko jmp-opkoodi, koska goto on sen vastike.

Lue lisää

"Goton voi aina ohittaa jollain muulla lauserakenteella"

Ei voi.

Toki 99% tapauksista on sellaisia, joissa GOTOn voi hyvin korvata muulla lauserakenteella, esim FOR, WHILE tai REPEAT.

Mutta se loppu 1%, siinä GOTOa ei voi korvata millään.

Tiedän ainakin yhden algoritmin, joka on koodattu Delphillä, eikä sitä voi kääntää JAVAksi, kun siinä on tarvittu GOTO -käskyä, ja tuota GOTOa on käytetty siten, ettei sitä voi korvata muulla lauserakenteella.

Yleensä ei. Kaunis koodi on sellaista, jossa on optimoitu ylläpidettävyyttä/rakennetta. Tämän optimointi vaikuttaa myönteisesti ihan kaikkiin asioihin ohjelman laadussa, myös suorituskykyyn.

M-Kar kirjoitti:

Yleensä ei. Kaunis koodi on sellaista, jossa on optimoitu ylläpidettävyyttä/rakennetta. Tämän optimointi vaikuttaa myönteisesti ihan kaikkiin asioihin ohjelman laadussa, myös suorituskykyyn.

Lue lisää

No joo, totta tuokin. Nähtävästi tämää menee taas termeisä saivarteluksi.

Mitä se "kaunis" nyt missäkin yhteydessä tarkoittaa . . .

Minun käsityksen mukaan, olio-ohjelmoinnilla saadaan monesti kauniimpi ja helpommin ylläpidettävä lopputulos, mutta mitään erityistä suorituskykyä se ei automaattisesti tuo, vaan päinvastoin huonosti toteutettuna sillä on helpompi tehdä sellaisia virheitä, mitkä johtavat hitaampaan suoritukseen.

öäöäö kirjoitti:

No joo, totta tuokin. Nähtävästi tämää menee taas termeisä saivarteluksi.

Mitä se "kaunis" nyt missäkin yhteydessä tarkoittaa . . .

Minun käsityksen mukaan, olio-ohjelmoinnilla saadaan monesti kauniimpi ja helpommin ylläpidettävä lopputulos, mutta mitään erityistä suorituskykyä se ei automaattisesti tuo, vaan päinvastoin huonosti toteutettuna sillä on helpompi tehdä sellaisia virheitä, mitkä johtavat hitaampaan suoritukseen.

Lue lisää

Olio-ohjelmointi on itseasiassa vielä suhteellisen matalan tason hinkkaamista.

Ensiksi puretaan ongelma korkean tason komponenteiksi, eli palveluiksi mitkä huolehtii tiedon tallentamista ja lukemista sekä erilaisia käyttöliittymä näkymiä tai vaikka tehdään palikoita tietovirtaan jotka ottaa dataa sisään ja lähettää muokattuna ulos.

Korkean tason rakennetta kun on tehnyt niin olio-ohjelmointia tärkeämpää on funktionaalisuus sekä se, että ongelma on purettu ikään kuin liukuhihnaksi.

Oliorakenteen tavoittelu tulee vasta näiden jälkeen, ja oliorakenteessa löytyy varsin näppäriä menetelmiä laskea kuinka hyvä jokin rakenne on.

Oliorakenteesta ei käytännössä ikinä kannata mennä heikompaan suuntaan.

M-Kar kirjoitti:

Olio-ohjelmointi on itseasiassa vielä suhteellisen matalan tason hinkkaamista.

Ensiksi puretaan ongelma korkean tason komponenteiksi, eli palveluiksi mitkä huolehtii tiedon tallentamista ja lukemista sekä erilaisia käyttöliittymä näkymiä tai vaikka tehdään palikoita tietovirtaan jotka ottaa dataa sisään ja lähettää muokattuna ulos.

Korkean tason rakennetta kun on tehnyt niin olio-ohjelmointia tärkeämpää on funktionaalisuus sekä se, että ongelma on purettu ikään kuin liukuhihnaksi.

Oliorakenteen tavoittelu tulee vasta näiden jälkeen, ja oliorakenteessa löytyy varsin näppäriä menetelmiä laskea kuinka hyvä jokin rakenne on.

Oliorakenteesta ei käytännössä ikinä kannata mennä heikompaan suuntaan.

Lue lisää

Mitkä asiat mielestäsi kuuluu olio-ohjelmointiin? Miten määrittelet olio-ohjelmoinnin?
Kerro ihan lyhyesti, vain pääkohdat.

Olio-ohjelma kirjoitti:

Mitkä asiat mielestäsi kuuluu olio-ohjelmointiin? Miten määrittelet olio-ohjelmoinnin?
Kerro ihan lyhyesti, vain pääkohdat.

Olio-ohjelmointi on oleellisesti sitä, että mallinnetaan ongelma objekteina (olio). Vähän niin kuin ohjelmoitavia tietotyyppejä jotka kommunikoivat keskenään. Oleellista olio-ohjelmoinnissa on instanssin käsite, että oliot ovat luokkien instansseja.

Käytännössä kyse on tavasta mallintaa ongelmaa. Oliomallinnusta sitten on helppo analysoida koska se mikä on sitten sitä kaunista ja suorituskykyistä on sellainen jossa on suuri koheesio.

Siihenhän sitä ohjelmoinnissa pyritään. suuri koheesio, pieni määrä kytkentöjä, ja ennen kaikkea sitä, että samaa tietoa ei muokata kuin yhdestä paikasta.

Sellaisia "olio-ohjelmoinnin pääkäsitteet" mitä on esitetty on myös kapselointi, polymorfismi ja perintä mutta ei pitäisi takertua liikaa tuohon. Ne ovat vain työkaluja auttamassa siinä ongelman mallinnuksessa oliopohjaisesti.

Jep, itse kyllä suosin returnto komentoa.

Jos goto on huono ohmelmoinita ja sitä kun ei oliohommissa käytetä niin miksi ihmeessä suurin osa näidän koodiapinoisden tekmisistä on on ihan kuraa. Vikaa, vikaa ja vikaa. Ylläpidettävyys on täysin tuntematon käsite kun ekassa releasessa yritetään tehdän maailman parasta ja optimoitua. 5 releasea myöhemmin koodi on täyttä spagettia.

Ihan sama vaikka tekisi pelkällä gotolla koodin jos siinä huomioidaan että jokaista toiminnallisuutta tullaan muuttamaan ja sen tekee täysin eri henkiöt jotka koodin alunperin teki. Siinä punnitaan onko koodi alunperin fiksusti suunniteltu.