Onko ruma kaunista?

Se on hyvin jännä homma kun näkee toisinaan sellaista touhua, että ohjelmoija takertuu jonkin muinaiseen ohjelmointikieleen tai käytäntöön, tai vaikka ruman näköiseen ohjelmointityyliin eikä yhtään yritä parantaa.

Vielä jännempiä on ne perustelut, kun muu maailma mennyt eteenpäin ja samat asiat saadaan tehtyä selkeämmin ja bugittomammin. Jopa ilman että tarvitsisi välttämättä työkalujakaan vaihtaa.
Ilmianna
Jaa

29 Vastausta



Rumahan voi olla kaunista, riipuen katsojan mieltymyksistä
Ilmianna
Jaa
Tämä ei liity tietotekniikkaan, mutta ulkonäköön.
Bulldoggikin on niin ruma, että suurinosa katsojista on haltioissaan.
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
Koodin kauneus taas liittyy tietotekniikkaan.

Siinä kun on yhteys bugisuuteen.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Onneksi minä huomasin pienenpänä poikana että aamukahvi maistui paremmalta Pariisin katukahviloissa kuin jossaan hämyisessä ohjelmointiputkassa Suomessa.
Kommentoi
Ilmianna
Jaa
5 VASTAUSTA:
Kahvihan maistuu parhaalle tulilla keitettynä (metässä), eikä missään vtun kahvilassa.
Kommentoi
Ilmianna
Jaa
hinttioletvarmaan kirjoitti:
Kahvihan maistuu parhaalle tulilla keitettynä (metässä), eikä missään vtun kahvilassa.
Mene metsään pikkupaskiainen.
Kommentoi
Ilmianna
Jaa
"bulls.shit" oletko homo ?
Kommentoi
Ilmianna
Jaa
bulls.shit kirjoitti:
Mene metsään pikkupaskiainen.
Niin menenki mettään, mistä arvasit? Liekkö siellä pariisin katukahviloissa kasvatetaan epänormaaleja miehiä?
Kommentoi
Ilmianna
Jaa
hintti.olet kirjoitti:
Niin menenki mettään, mistä arvasit? Liekkö siellä pariisin katukahviloissa kasvatetaan epänormaaleja miehiä?
Ihmeellisiä nämä pikkupojut!
Jotenkin tuntuu nykyään tuo homottelu/hintittely kuuluvan teini-ikäisten kehittymättömään sukupuolisuuteen.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Jossä kodaat samala tavala kun täne kirjotat nii maahtaa sun kodii ola melkoita sotkuu
Kommentoi
Ilmianna
Jaa
2 VASTAUSTA:
Sinulla selvästi jotain aloittajaa vastaan, mitä?
Kommentoi
Ilmianna
Jaa
bull.shit.gay kirjoitti:
Sinulla selvästi jotain aloittajaa vastaan, mitä?
Olematta whoopy kaikkihan tietää että aloittaja (on mielestään) aina oikeassa.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Noin > 99,999 % maapallon asukkaista ei ole ohjelmoijia, eikä tarvitse ollakaan, joten kovin "valtava" mahtaa ollakin se kaunista koodia silmät tapillaan töllöttävä yleisö.
Kommentoi
Ilmianna
Jaa
4 VASTAUSTA:
Aasian maissa on miljoonia tai kymmeniä miljoonia ammattiohjelmoijia, joka tekee yli promillen maapallon väestöstä.
Länsimaissa ohjelmoijia on paljon vähemmän, koska kaikki vähänkin suuremmat ohjelmistotalot ovat ulkoistaneet kaiken ohjelmoinnin aasiaan jossa ohjelmoijien palkat ovat matalia, eikä ohjelmistoyrityksissä ole töissä ensimmäistäkään ohjelmoijaa. Koskee myös suomalaisia suurempia ohjelmistofirmoja (esim. Accenture Finland jossa ei ole yhtään ohjelmoijaa töissä) - suomalaiset ja muutkin länsimaiset ohjelmoijat ovat kaikki työttömiä tai hyvin pienissä puljuissa töissä.
Kommentoi
Ilmianna
Jaa
ohjelmoijat_aasialaisia kirjoitti:
Aasian maissa on miljoonia tai kymmeniä miljoonia ammattiohjelmoijia, joka tekee yli promillen maapallon väestöstä.
Länsimaissa ohjelmoijia on paljon vähemmän, koska kaikki vähänkin suuremmat ohjelmistotalot ovat ulkoistaneet kaiken ohjelmoinnin aasiaan jossa ohjelmoijien palkat ovat matalia, eikä ohjelmistoyrityksissä ole töissä ensimmäistäkään ohjelmoijaa. Koskee myös suomalaisia suurempia ohjelmistofirmoja (esim. Accenture Finland jossa ei ole yhtään ohjelmoijaa töissä) - suomalaiset ja muutkin länsimaiset ohjelmoijat ovat kaikki työttömiä tai hyvin pienissä puljuissa töissä.
Höpö höpö.

Ohjelmoijien määrä on kasvanut koko ajan hyvin nopeaa tahtia.
Kommentoi
Ilmianna
Jaa
Jos esittää prosenttilukuja, niin sullahan täytyy olla jossakin lista kaikista maailman ohjelmoijista?

Epäilen, että sellaista listaa on olemassakaan, eli vetäisit luvut hatusta ja vieläpä täysin päin persettä.

0,001 % maailman väestöstä olisi noin 70 000 ihmistä, joka on reippaasti alakanttiin.

Toisaalta tuolla ohjelmoijien määrällä suhteessa väestöön ei niinkään ole tämän asian kannalta väliä, vaan sillä, mitkä on seuraukset.

Eihän ruokaakaan tuota kehittyneissä maissa nykyään kuin hyvin pieni osa koko väestöstä, silti kaikki on arvioimassa työn tuloksia.

Koko työtä tekevä väestö maksaa huonosti tehdystä ohjelmistosta. Eriomaisia esimerkkejä terveydenhuollon tietojärejstelmät, sähköinen resepti . . .
Kommentoi
Ilmianna
Jaa
Miljardit ihmiset käyttää sitä koodia eri muodoissa.

Tunnetusti sotkuinen koodi on bugisempaa, joten asialla on paljonkin merkitystä.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Kauneus on katsojan silmässä ja siis kovin subjektiivista . . .

Kyllä nämä Bob Martinin luennot on aika hyviä:
https://www.youtube.com/watch?v=TMuno5RZNeE
Ilmianna
Jaa
Ärsyttävintä on se, kun omasta mielestä koodi on kaunista ja toisen mielestä asia pitäisi tehdä selkeämmin. Sitten ei osattukaan antaa eksplisiittisiä selkeyskriteerioita. Parempi olisi tietty joku koodin analysoija, joka ilmoittaisi tai jopa korjaisi epäselkeät kohdat.
Kommentoi
Ilmianna
Jaa
4 VASTAUSTA:
Onhan noita muutamia.

1. 100% test coverage:

Yleensä tuskin on läpipaskaa koodia jotta saa sen testattavaksi

2. Liittyen edelliseen, Pienempi Cyclomatic complexity == vähemmän testien kirjoittamista.

3. Halstead complexity: Mittaa kivasti itse koodin ulkoasun kompleksisuutta

4. Rivimäärä. Vähemmän on parempi

5. Sivuvaikutusten minimointi. Koodin pätkä ei oikein saisi vaikuttaa muualle. Keinoja tähän on esim. tilattomuus, muuttumattomat tiedot, kytkentöjen ja riippuvuusten minimointi...

6. Koodi on itsedokumentoiva. Ei tarvitse erillistä dokumentaatiota kertomaan mitä koodi tekee vaan kirjoittu koodi samassa tiedostossa kertoo itsessään mitä tekee ja testit kertovat hyväksymisvaatimuksen niin että sen lukeminen ei tarvitse ohjelmoijaa.

Onhan noita linttereitä myös olemassa mitkä siivoilee typeryyksiä.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Onhan noita muutamia.

1. 100% test coverage:

Yleensä tuskin on läpipaskaa koodia jotta saa sen testattavaksi

2. Liittyen edelliseen, Pienempi Cyclomatic complexity == vähemmän testien kirjoittamista.

3. Halstead complexity: Mittaa kivasti itse koodin ulkoasun kompleksisuutta

4. Rivimäärä. Vähemmän on parempi

5. Sivuvaikutusten minimointi. Koodin pätkä ei oikein saisi vaikuttaa muualle. Keinoja tähän on esim. tilattomuus, muuttumattomat tiedot, kytkentöjen ja riippuvuusten minimointi...

6. Koodi on itsedokumentoiva. Ei tarvitse erillistä dokumentaatiota kertomaan mitä koodi tekee vaan kirjoittu koodi samassa tiedostossa kertoo itsessään mitä tekee ja testit kertovat hyväksymisvaatimuksen niin että sen lukeminen ei tarvitse ohjelmoijaa.

Onhan noita linttereitä myös olemassa mitkä siivoilee typeryyksiä.
"Rivimäärä. Vähemmän on parempi"

Ei pidä paikkaansa.

"Koodi on itsedokumentoiva. Ei tarvitse erillistä dokumentaatiota kertomaan mitä koodi tekee vaan kirjoittu koodi samassa tiedostossa kertoo itsessään mitä tekee ja testit kertovat hyväksymisvaatimuksen niin että sen lukeminen ei tarvitse ohjelmoijaa."

Tämähän on täysin ristiriidassa kohdan 4 kanssa.

Miten kirjoitat "itsedokumentoivaa" koodia minimoiden rivimääränkin? Koodin kommentit kääntäjät jättää huomioimatta, niitä voi ja pitäisi olla enemmän kuin itse koodia. Aina. Niillä varmistetaan se, että koodia lukeva oikeasti ymmärtää mitä koodi tekee. VARMISTETAAN.
Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Äh, suomi24 ei mahdollista sisennyksiä. Taulunkon pitää taulukko, ja { jälkeen seuraavat rivit sisennettynä.
Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Siltä varalta että suomi24:n robotti ei ymmärrä koodia:

"Tämähän on täysin ristiriidassa kohdan 4 kanssa."

Ei mitenkään. Toteutus pitää olla tehtävissä minimimäärällä koodirivejä, mutta luettavuussyistä pitää olla lauseke per rivi, ja tyhjiä rivejä että tulee luettavia blokkeja ja rivin pituudet pitää myös olla esim. sisennys + 70 merkkiä.

"Miten kirjoitat "itsedokumentoivaa" koodia minimoiden rivimääränkin? Koodin kommentit kääntäjät jättää huomioimatta, niitä voi ja pitäisi olla enemmän kuin itse koodia. Aina. Niillä varmistetaan se, että koodia lukeva oikeasti ymmärtää mitä koodi tekee. VARMISTETAAN. "

Tuo tarkoittaa sitä, koodi on niin paskaa että pitää kirjoittaa erikseen selitystä mitä se tekee ja siinä sitten pitää ylläpitää

Mutta otetaan esimerkki jos vaikka kirjoittaisi testiä, niin sen voisi kirjoittaa vaikka näin:

https://pastebin.com/YrvmHP2F

Tai jos tekee toteutusta niin voi tehdä itsedokumentoimavasti vaikka päätöstaulun, esimerkki Javascriptiä:

https://pastebin.com/mrtSDP10

Että mitähän tuossa nyt tarvitsisi sitten vielä dokumentoida kun koodia voi kirjoittaa myös tähän tapaan itsedokumentoivasti?
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Joskus ns. ruma koodi on siellä koska se voi olla ylläpidettävämpää niiden toimesta jotka ei kuitenkaan ymmärtäisi ns. hienouksia. Näin saadaan softa toimimaan pidempään kunnolla ja sehän se on kaikkein tärkeintä, ei kikkailu.

Ylipäänsä koodin optimointi alussa on aika tyhmää. Arkkitehtuurin optimointi myös jos haetaan vain sen hetkisen tiedon valossa optimiratkaisua. Se jos mikä on idioottimaista, olkoon sitten vaikka kuinka kaunista.

10 vuotta ylläidetty ja uusia ominaisuuksia lisäilty koodi on sen luokan spagettia että alussa loppuun optimoitu onkäytännössä pakko kirjoittaa uudestaan. Joku yksinkertaiseen perusperiatteeseen perutuva mutta kaunistelematon on useimmiten paremmassa kunnossa satojen muutoksien jälkeen.
Kommentoi
Ilmianna
Jaa
5 VASTAUSTA:
Koodin kauneuden optimointi on sitä, että kuinka hyvin se on hallittavissa. Se menee yleensä käsikädessä arkkitehtuurin optimoinnin kanssa. Kaunis koodi nimenomaan ei ole mitään spagettia.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Koodin kauneuden optimointi on sitä, että kuinka hyvin se on hallittavissa. Se menee yleensä käsikädessä arkkitehtuurin optimoinnin kanssa. Kaunis koodi nimenomaan ei ole mitään spagettia.
Huoh.

Mitä jos kuuntelisitte Linus Torvaldsin ja vastaavien mielipiteitä asiasta.

Linux on varmaan maailman suurin ohjelmistoprojekti, kehittäjien määrässä mitattuna. Siihen osallistuu käytännössä kaikki talot, halusi tai ei. Jokainen joka urputtaa Torvaldsille siitä että Linuxissa on jotain 100 000 goto lausetta, ovat nopeasti lopettaneet pätemisensä.

Koodin kauneudella ei ole mitään merkitystä jos sen hinnalla saadaan muistisyöppö, paskasti käännetty ohjelma. Ohjelmistokehityksessä pääpaino tulisi olla ajonaikaisessa testauksessa eikä missään vitun filosofiassa. Harva C-kääntäjä ymmärtää taidetta.

Ohjelmointi on vähän monimutkaisempi asia kuin se korkean tason kielen siisteys. Korkean tason kielet pyritään pitämään siisteinä virheiden minimoimiseksi, mutta kääntäjä ja lopulta ajonaikainen ympäristö päättää miten se koodi oikeasti toimii.

Kun sinä ajattelet vain sitä korkean tason kielen hallintaa, jotkut muut valvovat yönsä sinun takiasi, ymmärrätkö? Tämä ei ole oikeasti niin yksinkertaista kuin jonkin sinfonian säveltäminen.
Kommentoi
Ilmianna
Jaa
napunapunapu kirjoitti:
Huoh.

Mitä jos kuuntelisitte Linus Torvaldsin ja vastaavien mielipiteitä asiasta.

Linux on varmaan maailman suurin ohjelmistoprojekti, kehittäjien määrässä mitattuna. Siihen osallistuu käytännössä kaikki talot, halusi tai ei. Jokainen joka urputtaa Torvaldsille siitä että Linuxissa on jotain 100 000 goto lausetta, ovat nopeasti lopettaneet pätemisensä.

Koodin kauneudella ei ole mitään merkitystä jos sen hinnalla saadaan muistisyöppö, paskasti käännetty ohjelma. Ohjelmistokehityksessä pääpaino tulisi olla ajonaikaisessa testauksessa eikä missään vitun filosofiassa. Harva C-kääntäjä ymmärtää taidetta.

Ohjelmointi on vähän monimutkaisempi asia kuin se korkean tason kielen siisteys. Korkean tason kielet pyritään pitämään siisteinä virheiden minimoimiseksi, mutta kääntäjä ja lopulta ajonaikainen ympäristö päättää miten se koodi oikeasti toimii.

Kun sinä ajattelet vain sitä korkean tason kielen hallintaa, jotkut muut valvovat yönsä sinun takiasi, ymmärrätkö? Tämä ei ole oikeasti niin yksinkertaista kuin jonkin sinfonian säveltäminen.
"Koodin kauneudella ei ole mitään merkitystä jos sen hinnalla saadaan muistisyöppö, paskasti käännetty ohjelma."

Ennemminkin päinvastoin. Kaunis koodi on bugittomampaa ja nopeampaa eikä rohmua kaikkea muistia.

"Harva C-kääntäjä ymmärtää taidetta."

Kyllä C:lläkin voi tehdä kaunista koodia. Samainen päätöstaulu C:llä minkä tuossa yllä tein Javascriptillä.

Javascriptillä näkyy onnistuvan vastaavan tekeminen hieman nätimmin. Tosin pitää ottaa huomioon, että C on systeemiohjelmointiin ja Javascript sovelluksille, että painottavat vähän eri asioita. C:llä tulee selvästikin enemmän rivejä.

'#define DT_NAME_LEN 32
'#define DT_PRINTER_TROUBLESHOOTER_SIZE 16
'
'typedef struct DT_PrinterTroubleShooterRowTag {
' char name[DT_NAME_LEN];
' char row[DT_PRINTER_TROUBLESHOOTER_SIZE];
'} DT_PrinterTroubleShooterRow;
'
'DT_PrinterTroubleShooterRow printerTroubleShooterConditions[3] = {
' {"Printer prints", "N|N|N|N|Y|Y|Y|Y"},
' {"A red light is flashing", "Y|Y|N|N|Y|Y|N|N"},
' {"Printer is recognized by computer", "N|Y|N|Y|N|Y|N|Y"}
'}

"Korkean tason kielet pyritään pitämään siisteinä virheiden minimoimiseksi, mutta kääntäjä ja lopulta ajonaikainen ympäristö päättää miten se koodi oikeasti toimii."

Ohjelmointikielen tarkoitus on muuntaa ohjelmoijan tietokoneelle ilmaisemat ajatukset tietokoneen ymmärrettävässä muodossa. Ohjelmointikielellä siis ilmaistaan ajatuksia tietokoneelle. Se on sitten sen kääntäjän, tulkin tai minkä tahansa ajoympäristön asia kääntää tai tulkata se. Ohjelmoijan tehtävä taas on kirjoittaa koodi oikein että siinä ei ole mitään bugeja.

IDE, kääntäjät ja tulkit yms. työkalut sitten huomaavat virheitä kun ohjelmoija syöttää sitä koodia ja ne korjataan, mutta näiden lisäksi ohjelmoija myös kirjoittaa testejä, että varmistetaan että koodi toimii oikein. Testit vieläpä kirjoitetaan normaalisti ensiksi ja ne toimivat osana ohjelman määrittelyä.
Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Kommentoi
Ilmianna
Jaa
napunapunapu kirjoitti:
Huoh.

Mitä jos kuuntelisitte Linus Torvaldsin ja vastaavien mielipiteitä asiasta.

Linux on varmaan maailman suurin ohjelmistoprojekti, kehittäjien määrässä mitattuna. Siihen osallistuu käytännössä kaikki talot, halusi tai ei. Jokainen joka urputtaa Torvaldsille siitä että Linuxissa on jotain 100 000 goto lausetta, ovat nopeasti lopettaneet pätemisensä.

Koodin kauneudella ei ole mitään merkitystä jos sen hinnalla saadaan muistisyöppö, paskasti käännetty ohjelma. Ohjelmistokehityksessä pääpaino tulisi olla ajonaikaisessa testauksessa eikä missään vitun filosofiassa. Harva C-kääntäjä ymmärtää taidetta.

Ohjelmointi on vähän monimutkaisempi asia kuin se korkean tason kielen siisteys. Korkean tason kielet pyritään pitämään siisteinä virheiden minimoimiseksi, mutta kääntäjä ja lopulta ajonaikainen ympäristö päättää miten se koodi oikeasti toimii.

Kun sinä ajattelet vain sitä korkean tason kielen hallintaa, jotkut muut valvovat yönsä sinun takiasi, ymmärrätkö? Tämä ei ole oikeasti niin yksinkertaista kuin jonkin sinfonian säveltäminen.
Tehdään viesti vielä uusiksi, tuo pastebin näkyy sopivan suomi24 käyttöön:

"Koodin kauneudella ei ole mitään merkitystä jos sen hinnalla saadaan muistisyöppö, paskasti käännetty ohjelma."

Ennemminkin päinvastoin. Kaunis koodi on bugittomampaa ja nopeampaa eikä rohmua kaikkea muistia.

"Harva C-kääntäjä ymmärtää taidetta."

Kyllä C:lläkin voi tehdä kaunista koodia. Samainen päätöstaulu C:llä minkä tuossa yllä tein Javascriptillä.

https://pastebin.com/uBFwvTGg

Javascriptillä näkyy onnistuvan vastaavan tekeminen hieman nätimmin. Tosin pitää ottaa huomioon, että C on systeemiohjelmointiin ja Javascript sovelluksille, että painottavat vähän eri asioita. C:llä tulee selvästikin enemmän rivejä.

"Korkean tason kielet pyritään pitämään siisteinä virheiden minimoimiseksi, mutta kääntäjä ja lopulta ajonaikainen ympäristö päättää miten se koodi oikeasti toimii."

Ohjelmointikielen tarkoitus on muuntaa ohjelmoijan tietokoneelle ilmaisemat ajatukset tietokoneen ymmärrettävässä muodossa. Ohjelmointikielellä siis ilmaistaan ajatuksia tietokoneelle. Se on sitten sen kääntäjän, tulkin tai minkä tahansa ajoympäristön asia kääntää tai tulkata se. Ohjelmoijan tehtävä taas on kirjoittaa koodi oikein, että siinä ei ole mitään bugeja.

IDE, kääntäjät ja tulkit yms. työkalut sitten huomaavat virheitä kun ohjelmoija syöttää sitä koodia ja ne korjataan, mutta näiden lisäksi ohjelmoija myös kirjoittaa testejä, että varmistetaan että koodi toimii oikein. Testit vieläpä kirjoitetaan normaalisti ensiksi ja ne toimivat osana ohjelman määrittelyä.

...

Eri kielissä, kääntäjissä jne. on toki erilaisia ominaisuuksia. Joissakin on esimerkiksi tehty tietyntyyppisten virheiden tekeminen mahdottomaksi tai voi olla eroja suorituskyvyssä kun tekee tiettyjä asioita tai IDE voi tarkistaa asioita reaaliajassa eri tavoin, koodin luettavuus voi olla eri, voi olla erilaisia toimintoja valmiina standardikirjastossa tai kielen syntaksissa, voi olla standardisoitu jne.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Tehdään viesti vielä uusiksi, tuo pastebin näkyy sopivan suomi24 käyttöön:

"Koodin kauneudella ei ole mitään merkitystä jos sen hinnalla saadaan muistisyöppö, paskasti käännetty ohjelma."

Ennemminkin päinvastoin. Kaunis koodi on bugittomampaa ja nopeampaa eikä rohmua kaikkea muistia.

"Harva C-kääntäjä ymmärtää taidetta."

Kyllä C:lläkin voi tehdä kaunista koodia. Samainen päätöstaulu C:llä minkä tuossa yllä tein Javascriptillä.

https://pastebin.com/uBFwvTGg

Javascriptillä näkyy onnistuvan vastaavan tekeminen hieman nätimmin. Tosin pitää ottaa huomioon, että C on systeemiohjelmointiin ja Javascript sovelluksille, että painottavat vähän eri asioita. C:llä tulee selvästikin enemmän rivejä.

"Korkean tason kielet pyritään pitämään siisteinä virheiden minimoimiseksi, mutta kääntäjä ja lopulta ajonaikainen ympäristö päättää miten se koodi oikeasti toimii."

Ohjelmointikielen tarkoitus on muuntaa ohjelmoijan tietokoneelle ilmaisemat ajatukset tietokoneen ymmärrettävässä muodossa. Ohjelmointikielellä siis ilmaistaan ajatuksia tietokoneelle. Se on sitten sen kääntäjän, tulkin tai minkä tahansa ajoympäristön asia kääntää tai tulkata se. Ohjelmoijan tehtävä taas on kirjoittaa koodi oikein, että siinä ei ole mitään bugeja.

IDE, kääntäjät ja tulkit yms. työkalut sitten huomaavat virheitä kun ohjelmoija syöttää sitä koodia ja ne korjataan, mutta näiden lisäksi ohjelmoija myös kirjoittaa testejä, että varmistetaan että koodi toimii oikein. Testit vieläpä kirjoitetaan normaalisti ensiksi ja ne toimivat osana ohjelman määrittelyä.

...

Eri kielissä, kääntäjissä jne. on toki erilaisia ominaisuuksia. Joissakin on esimerkiksi tehty tietyntyyppisten virheiden tekeminen mahdottomaksi tai voi olla eroja suorituskyvyssä kun tekee tiettyjä asioita tai IDE voi tarkistaa asioita reaaliajassa eri tavoin, koodin luettavuus voi olla eri, voi olla erilaisia toimintoja valmiina standardikirjastossa tai kielen syntaksissa, voi olla standardisoitu jne.
Perehdy Linuxin johtoportaan mietteisiin aiheesta.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti

Vastaa alkuperäiseen viestiin

Onko ruma kaunista?

Se on hyvin jännä homma kun näkee toisinaan sellaista touhua, että ohjelmoija takertuu jonkin muinaiseen ohjelmointikieleen tai käytäntöön, tai vaikka ruman näköiseen ohjelmointityyliin eikä yhtään yritä parantaa.

Vielä jännempiä on ne perustelut, kun muu maailma mennyt eteenpäin ja samat asiat saadaan tehtyä selkeämmin ja bugittomammin. Jopa ilman että tarvitsisi välttämättä työkalujakaan vaihtaa.

5000 merkkiä jäljellä

Peruuta