Olemme kaikki tehneet sen: tarttunut evästeeseen, kun äiti ei etsinyt, juonut vähän liikaa viiniä päivälliseksi, anna auton istua pysäköintialueella mittarin umpeutumisen jälkeen. Olemme jopa kiertäneet Deadmanin kaaren hieman liian nopeasti. Ja kyllä, olemme kaikki rikkoneet useita ohjelmoinnin pääsääntöjä, joista kaikki ovat yhtä mieltä. Ja pidimme salaa siitä.
Olemme peukaloittaneet nenäämme hyvän ohjelmoinnin sääntöihin, kirjoittaneet täysin huonon koodin - ja olemme eläneet. Ohjelmointijumalilla ei ollut salamoita. Pöytätietokoneemme eivät räjähtäneet. Itse asiassa koodimme koottiin ja lähetettiin, ja asiakkaat näyttivät riittävän onnellisilta.
Tämä johtuu siitä, että huono ohjelmointi ei ole samassa liigassa kuin esimerkiksi aitauksen nuoleminen tai tiikerin hännän vetäminen. Suurimman osan ajasta se toimii. Säännöt ovat useammin suuntaviivoja tai tyylisuunnitelmia, eivät kovaa ja nopeaa direktiiviä, jota on noudatettava tai koodikuolema seuraa. Toki, koodisi saatetaan pilkata, mahdollisesti jopa julkisesti. Mutta se, että pidät sopimuksia, lisää hieman jännitystä siitä, että jopa vahingossa vahingoitetaan sitä, mikä tarkoittaa (useimmiten) miellyttävän koodin sosiaalisia tapoja.
Jos haluat tehdä asioista monimutkaisempia, on joskus parempi rikkoa sääntöjä. (Shhhh!) Koodi tulee puhtaammaksi. Se voi olla jopa nopeampi ja yksinkertaisempi. Säännöt ovat yleensä hieman liian laajoja, ja taitava ohjelmoija voi parantaa koodia rikkomalla niitä. Älä kerro pomollesi, mutta joskus on järkevää koodata oma tapa.
Seuraavassa on luettelo yhdeksästä säännöstä, joita jotkut saattavat pitää mahdottomina, mutta monet meistä rikkovat usein sekä menestyksellä että ilolla.
Huono ohjelmointitapa nro 1: Kopiointi
On väärin tehdä se koulussa. Työssä säännöt eivät ole niin selkeät. On varmasti joitain koodilohkoja, joita ei pitäisi varastaa. Jos se tulee omasta koodista, älä taita sitä pinoon, varsinkin jos se on merkitty tekijänoikeusviestillä. Kirjoita oma versio. Se mitä he maksavat sinulle tekemisestä.
Hankalampi kysymys tulee, kun alkuperäinen luoja haluaa jakaa. Ehkä se on yhdellä näistä online-ohjelmointifoorumeista. Ehkä se on avoimen lähdekoodin lisenssi (BSD, MIT), joka sallii toiminnon tai kolmen napsauttamisen. Mikään oikeudellinen syy ei estä sinua. Ja sinulle maksetaan ongelmien ratkaisemisesta, ei pyörän keksimisestä uudelleen.
Suurimman osan ajasta kopioinnin edut ovat pakottavia, ja haittoja voidaan rajoittaa vähän huolella. Koodista, jonka saat hyvämaineisesta lähteestä, on jo sovellettu ainakin yhtä ajatuskierrosta. Alkuperäinen kirjoittaja etsi ratkaisua ja löysi jotain. Silmukkavaihtajat ja tietovirta on selvitetty.
Hankalat kysymykset ovat, onko roolissa tai taustalla olevissa tiedoissa joitain perusteettomia virheitä vai erilaisia oletuksia. Ehkä koodisi sekoittuu nollaosoittimiin, vaikka alkuperäinen koodi ei ole koskaan tarkistanut niitä. Jos pystyt korjaamaan ongelmat, pomo on kuin saisi panoksen kahdelta ohjelmoijalta. Se on pariohjelmointi ilman hienoja pöytiä.
Huono ohjelmointitapa nro 2: Ei-toimiva koodi
Noin viime vuosikymmenen ajan toiminnallinen paradigma on noussut. Ohjelman rakentamisen sisäkkäisistä toiminnoista johtavat akolyytit kutsuvat rakkautta mainitsemaan tutkimuksia, jotka osoittavat, kuinka koodi on turvallisempi ja virheettömämpi kuin vanhempi muuttujien ja silmukoiden tyyli, jotka kaikki on yhdistetty millään tavalla, mikä tekee ohjelmoijasta onnellisen. Bhaktat puhuvat tosi uskovien innostuksesta ja kiusaavat toimimattomia lähestymistapoja koodien tarkasteluissa ja vetopyynnöissä. He saattavat olla oikeassa eduissaan.
Mutta joskus sinun tarvitsee vain päästä pois rullasta teippiä. Upeasti suunniteltu ja sulavasti suunniteltu koodi vie aikaa paitsi kuvittelemiseen, myös rakentamiseen ja myöhemmin navigointiin. Kaikki nämä kerrokset lisäävät monimutkaisuutta ja monimutkaisuus on kallista. Kaunien toiminnallisten koodien kehittäjien on suunniteltava eteenpäin ja varmistettava, että kaikki tiedot välitetään oikeita reittejä pitkin. Joskus on vain helpompaa tavoittaa muuttuja. Ehkä laita kommentti selittääksesi sen. Jopa pitkän, syvällisen anteeksipyynnön lisääminen tuleville sukupolville kommentissa on nopeampi kuin koko järjestelmän uudelleenrakentaminen tekemään se oikealla tavalla.
Huono ohjelmointitapa nro 3: Epätyypillinen väli
Suurimmalla osalla ohjelmiston tiloista ei ole vaikutusta ohjelman toimintaan. Muutamia kieliä lukuun ottamatta, kuten Python, jotka käyttävät välilyöntiä koodilohkojen osoittamiseen, useimmilla välilyönneillä ei ole vaikutusta ohjelman käyttäytymiseen. Silti on pakkomielteisiä ohjelmoijia, jotka laskevat heidät ja vaativat, että heillä on merkitystä. Yksi heistä kertoi kerran pomolleni vakavimmalla äänellä, että kirjoitin ”Ei-vakiokoodin”, ja hän näki sen heti. Minun syntini? ESLint space-infix-ops -säännön rikkominen jättämättä välilyöntiä yhtäläisyysmerkin molemmille puolille.
Joskus sinun täytyy vain miettiä jotain syvempää kuin tilojen sijoittelu. Ehkä olet huolissasi tietokannan ylikuormituksesta. Ehkä olet huolissasi siitä, että nollaosoitin saattaa kaataa koodisi. Melkein mikä tahansa koodin osa on tärkeämpi kuin välilyönnit, vaikka hämärät, ylelliset standardikomiteat olisivat täyttäneet sivuja sääntöjä näiden välilyöntien tai välilehtien sijoittamisesta.
Hämmästyttävää on, että on olemassa useita hyviä työkaluja, jotka muotoilevat koodisi automaattisesti noudattamaan kaikkia tarkasti määriteltyjä nukkaussääntöjä. Ihmisen ei tarvitse viettää aikaa ajatellessaan tätä. Jos se on niin tärkeää, he voivat käyttää sitä työkalun läpi ongelman puhdistamiseksi.
Huono ohjelmointitapa nro 4: Käyttäminen mene
Käyttökielto mene päivämäärät aikakauteen, ennen kuin monia strukturoidun ohjelmoinnin työkaluja edes oli olemassa. Jos ohjelmoijat haluavat luoda silmukan tai siirtyä toiseen rutiiniin, heidän on kirjoitettava MENE jota seuraa rivinumero. Muutaman vuoden kuluttua kääntäjäryhmät antoivat ohjelmoijien käyttää merkkijonoa rivinumeron sijaan. Sitä pidettiin tuolloin kuumana uutena ominaisuutena.
Jotkut kutsuivat tulosta spagettikoodiksi. Kukaan oli mahdotonta lukea koodiasi myöhemmin ja seurata suorituksen polkua. Se oli säikeiden sekoitus, ikuisesti takkuinen. Edsger Dijkstra kielsi komennon käsikirjoituksella, jonka otsikko oli ”Goto Statement Attickful Harmful”.
Mutta absoluuttinen haarautuminen ei ole ongelma. Se on takku, joka johtaa. Usein taitava tauko tai palata tarjoaa erittäin puhtaan lausunnon siitä, mitä koodi tekee kyseisessä paikassa. Joskus lisäämällä mene tapauslausekkeeseen tuottaa jotain, joka on yksinkertaisempi ymmärtää kuin asianmukaisemmin jäsennelty luettelo kaskadoitavista if-then-else-lohkoista.
On olemassa vasta-esimerkkejä. Applen SSL-pinon "goto fail" -turva-aukko on yksi parhaista tapauksista. Mutta jos olemme varovaisia välttääksemme joitain tapauslausekkeiden ja silmukoiden ongelmakohtia, voimme lisätä hyviä, absoluuttisia hyppyjä, jotka helpottavat lukijan ymmärtämistä, mitä tapahtuu. Voimme laittaa a tauko tai a palata se on puhtaampaa ja miellyttävämpää kaikille - paitsi ehkä mene vihaajat.
Huono ohjelmointitapa nro 5: Tyyppien ilmoittamatta jättäminen
Kirjoitettuja kieliä rakastavilla ihmisillä on asia. Kirjoitamme paremman, virheettömämmän koodin, kun lisätään selkeät ilmoitukset kunkin muuttujan tietotyypistä. Hetken keskeyttäminen tyypin selvittämiseksi auttaa kääntäjää ilmoittamaan tyhmät virheet ennen kuin koodi alkaa toimia. Se voi olla tuskaa, mutta se auttaa. Se on vöitä ja henkseleitä käyttävä lähestymistapa ohjelmointiin, joka pysäyttää virheet.
Ajat ovat muuttuneet. Monet uudemmista kääntäjistä ovat tarpeeksi älykkäitä päättelemään tyypin katsomalla koodia. He voivat työskennellä taaksepäin ja eteenpäin koodin läpi, kunnes voivat olla varmoja, että muuttujan on oltava a merkkijono tai an int tai jotain muuta. Ja jos nämä päätetyt tyypit eivät ole rivissä, kääntäjät voivat nostaa virhelipun. He eivät tarvitse meitä kirjoittamaan muuttujia enää.
Tämä tarkoittaa, että nyt on helpompaa säästää muutama bitti jättämällä pois yksinkertaisimmat ilmoitukset. Koodista tulee hieman puhtaampi, ja lukija pystyy yleensä melko arvaamaan, että muuttuja on nimetty i for for -silmukassa on kokonaisluku.
Huono ohjelmointitapa nro 6: jo-jo-koodi
Ohjelmoijat kutsuvat sitä mielellään "jo-jo koodiksi". Ensin arvot tallennetaan merkkijonoina. Sitten ne jäsennetään kokonaislukuiksi. Sitten ne muunnetaan takaisin jousiksi. Se on hirveän tehotonta. Voit melkein tuntea suorittimen kamppailevan kaiken ylimääräisen kuormituksen alla. Nopeat koodit kirjoittavat älykkäät ohjelmoijat suunnittelevat arkkitehtuurinsa tulosten minimoimiseksi. Heidän koodi toimii nopeammin suunnittelunsa vuoksi.
Mutta uskokaa tai älkää, joskus sillä on järkeä. Joskus sinulla on whiz-bang-kirjasto, joka tekee miljoonia älykkäitä asioita omassa mustassa laatikossa. Joskus pomo kirjoitti seitsemänluvun sekin lisensoidakseen kaikki nerot siinä mustassa laatikossa. Jos kirjasto haluaa tietoja merkkijonoina, annat ne kirjastoon merkkijonoina, vaikka muuntaisit ne äskettäin kokonaislukuiksi.
Toki, voit kirjoittaa koko koodisi muunnoksen minimoimiseksi, mutta se vie aikaa. Joskus on oikein, että koodi suorittaa ylimääräisen minuutin, tunnin, päivän tai jopa viikon, koska koodin uudelleenkirjoittaminen vie vielä enemmän aikaa. Joskus teknisen velan nousu on halvempaa kuin ensinnäkin oikean rakentaminen.
Joskus kirjasto ei ole oma koodi, mutta koodi, jonka kirjoitit itse kauan sitten. Joskus on nopeampaa muuntaa tiedot vielä kerran kuin kirjoittaa kaikki kyseisessä kirjastossa. Joten menet mukaan ja kirjoitat jo-jo koodia. Se on ok - olemme kaikki olleet siellä.
Huono ohjelmointitapa nro 7: Omien tietorakenteiden kirjoittaminen
Yksi vakiosäännöistä on, että ohjelmoijan ei pitäisi koskaan kirjoittaa koodia tietojen tallentamiseen, kun hän on suorittanut tietorakenteiden kurssin toisen vuodensa aikana. Joku muu on jo kirjoittanut kaikki tarvitsemamme tietorakenteet, ja heidän koodinsa on testattu ja testattu vuosien varrella. Se on mukana kielessä ja se on todennäköisesti ilmainen. Koodissasi voi olla vain vikoja.
Mutta joskus tietorakennekirjastot ovat hieman hitaita. Joskus ne pakottavat meidät rakenteeseen, joka voi olla vakio mutta väärä koodillemme. Joskus kirjastot pakottavat meidät muuttamaan tietoja uudelleen ennen rakenteen käyttöä. Joskus kirjastoissa on vyö- ja ripustussuojauksia, kuten kierteen lukitus, eikä koodissamme tarvita niitä.
Kun näin tapahtuu, on aika kirjoittaa omat tietorakenteemme. Joskus se on paljon, paljon nopeampi. Ja joskus se tekee koodistamme paljon puhtaamman, koska emme sisällytä kaikkia ylimääräisiä koodeja tietojen muotoilemiseen tarkalleen.
Huono ohjelmointitapa nro 8: Vanhanaikaiset silmukat
Kauan sitten joku C-kielen luoja halusi kapseloida kaikki abstraktit mahdollisuudet yhdeksi yksinkertaiseksi rakenteeksi. Alussa oli tehtävä joitain asioita, joitain tehtäviä joka kerta silmukan läpi ja jokin tapa kertoa, milloin kaikki oli tehty. Tuolloin se tuntui täysin puhtaalta syntaksilta äärettömien mahdollisuuksien vangitsemiseksi.
Se oli silloin. Nyt jotkut modernit kiroukset näkevät vain ongelmia. Liikaa asioita on meneillään. Kaikki nämä hyvyyden mahdollisuudet pystyvät myös yhtä voimakkaasti pahuuteen. Se tekee lukemisesta ja haukkumisesta paljon vaikeampaa. He rakastavat toiminnallisempaa paradigmaa, jossa ei ole silmukoita, vain luetteloihin sovelletut toiminnot, tietyille tiedoille yhdistetyt laskennalliset mallit.
On tilanteita, joissa silmukaton tapa on puhtaampi, varsinkin kun on vain yksi siisti toiminto ja taulukko. Mutta on aikoja, jolloin vanhanaikainen silmukka on paljon yksinkertaisempi, koska se voi tehdä paljon enemmän. Esimerkiksi ensimmäisen ottelun etsiminen on yksinkertaisempaa, kun voit lopettaa heti kun se löytyy.
Lisäksi kartoitustoiminnot kannustavat huolimattomampaa koodausta, kun tiedoille on tehtävä useita asioita. Kuvittele, että haluat ottaa absoluuttisen arvon ja sitten kunkin luvun neliöjuuren. Nopein ratkaisu on kartoittaa ensimmäinen toiminto ja sitten toinen, silmukoiden tietoja kahdesti.
Huono ohjelmointitapa nro 9: Silmukoiden purkaminen keskeltä
Jossain linjalla sääntöjen laatimisryhmä ilmoitti, että jokaisella silmukalla tulisi olla "invariantti", toisin sanoen looginen lause, joka on totta koko silmukan ajan. Kun invariantti ei ole enää totta, silmukka päättyy. Se on hyvä tapa ajatella monimutkaisia silmukoita, mutta se johtaa hulluihin kieltoihin - kuten kieltää meitä käyttämästä palata tai a tauko silmukan keskellä. Tämä on kielletyn säännön osajoukko mene lausunnot.
Tämä teoria on hieno, mutta se johtaa yleensä monimutkaisempaan koodiin. Harkitse tätä yksinkertaista tapausta, joka etsii taulukon yhdelle testin läpäisevälle merkinnälle:
sillä aikaa kun minä<>...
jos (testi (a [i]) palauta sitten [i];
...
}
Silmukan muuttumattomat ystävät haluavat mieluummin lisätä toisen loogisen muuttujan, kutsua sitä ei löydettyja käytä sitä näin:
kun taas ((notFound) && (i<>...
jos (testi (a [i])), niin eiLöytetty = väärä;
...
}
Jos tämä looginen luku on hyvin nimetty, se on hieno pala itse dokumentoivaa koodia. Se voi helpottaa kaikkien ymmärtämistä. Mutta se on myös lisännyt monimutkaisuutta. Ja se tarkoittaa toisen paikallisen muuttujan varaamista ja sellaisen rekisterin tukkimista, jonka kääntäjä saattaa olla tarpeeksi älykäs korjaamaan.
Joskus a mene tai hyppy on puhtaampaa.
Huono ohjelmointitapa nro 10: Operaattoreiden ja toimintojen uudelleenmäärittely
Jotkut hauskimmista kielistä antavat sinun tehdä todella kavalia asioita, kuten määritellä uudelleen niiden elementtien arvo, jotka näyttävät olevan jatkuvia. Esimerkiksi Python antaa sinun kirjoittaa TOSI = EPÄTOSI, ainakin versiossa 2.7 ja sitä ennen. Tämä ei luo jonkinlaista logiikkaa romahtaa ja maailmankaikkeuden loppua; se vain vaihtaa merkityksen TOTTA ja VÄÄRÄ. Voit myös pelata tällaisia vaarallisia pelejä C-esiprosessoreilla ja joillakin muilla kielillä. Muiden kielten avulla voit määrittää operaattorit, kuten plusmerkin, uudelleen.
Tämä on venytys, mutta isossa koodilohkossa on pisteitä, kun on nopeampaa määritellä yksi tai useampi näistä ns. Vakioista. Joskus pomo haluaa koodin tekevän jotain aivan erilaista. Toki, voit selvittää koodin ja muuttaa jokaisen tapahtuman tai voit määrittää todellisuuden uudelleen. Se voi saada sinut näyttämään nerolta. Sen sijaan, että kirjoittaisit valtavan kirjaston uudelleen, käännät vain vähän ja se päinvastoin.
Ehkä on hyvä vetää viiva tähän. Sinun ei pitäisi kokeilla tätä kotona riippumatta siitä, kuinka fiksu ja hauska se voi olla. Tämä on liian vaarallista - todella ... rehellistä.
