Mitä tarkoittaa “ hyvän koodin kirjoittaminen ”? [suljettu]

Hyviä kriteerejä ei oikeastaan ole kuin kuinka nopeasti ymmärrät koodin. Saat koodisi näyttämään hyvältä etsimällä täydellisen kompromissin ytimekkyyden ja luettavuuden välillä.

”WTF: n s minuutissa” (yllä) on totta, mutta se on vain seurausta yleisemmästä säännöstä. Mitä enemmän WTF-tiedostoja, sitä hitaampi ymmärtäminen.

Kommentit

• @rmx: määritä " työn tekeminen hyvin "
• No, että menetelmä RemoveCustomer poistaa itse asiassa kutomeerin kiertämättä. Voit viettää tunteja, jotta se näyttää kauniilta, mutta se ei tarkoita, että se todella toimii. ' Kuinka nopeasti ymmärrät koodin ', ei ole ainoa kriteeri ' hyvälle koodille ' on se, mitä sanon ' m.
• @rmx: mutta virheettömyys on epäselvää, isn ' onko se? Jos koodisi ei tee ' t työtä oikein, se ' ei vielä koodaa.
• @ rmx: itse asiassa ei. Jos koodisi on helppo ymmärtää, niin lopuksi se ' on helppo ymmärtää, jos se tekee sen huonosti '. OTOH, jos sitä on ' vaikea ymmärtää, sitä on ' vaikea ymmärtää, jos se tehdään ' työ ollenkaan.
• @rmx: PS Yksinkertaisesti sanottuna dekrementtisi () on klassinen WTF ja siten hidastaa koodin osien ymmärtämistä, joissa tätä toimintoa käytetään.

Koodi, joka on

1. virheetön

2. uudelleenkäytettävä

3. riippumaton

4. vähemmän monimutkainen

5. hyvin dokumentoitu

6. helppo haistaa

kutsutaan hyväksi koodiksi.

Hyvä ohjelma toimii moitteettomasti eikä siinä ole virheitä. Mutta mitkä sisäiset ominaisuudet tuottavat tällaista täydellisyyttä ?. Se ei ole mysteeri, tarvitsemme vain ajoittaisia muistutuksia. Koodaatpa sitten C / C ++, C #, Java, Basic, Perl, COBOL tai ASM, kaikilla hyvillä ohjelmoinnilla on samat kunnioitetut ominaisuudet: yksinkertaisuus, luettavuus, modulaarisuus , kerrostaminen, suunnittelu, tehokkuus, tyylikkyys ja selkeys, tehokkuus ja selkeys

Lähde: MSDN

Kommentit

• Yksinkertaisuus, luettavuus, tyylikkyys ja selkeys ovat kaikki samat. Modulaarisuus ja kerrostaminen ovat vain tapoja tehdä koodistasi selkeä Ainoa asia, joka jäljellä on luettelossa, on tehokkuus, joka on eräänlainen implisiittinen, ja sen lisäksi on usein kysymys tehokkuuden ja selkeyden kompromisseista.
• Tarkista tämä: goo.gl/hdQt8
• Koodi voi olla virheetön?
• Ei, se voi ' t. (käytännössä)
• Tehokas tulisi lisätä luetteloosi. Nopeus ei ole ' ei välttämätön on yleensä hyvän koodin ensisijainen indikaattori, mutta hyvä koodi ei saisi ' olla tarpeettoman hidas tai tuhlaavainen.

Näyttääkö tämä tutulta?

Philips antoi minulle mahdollisuuden katsella uuden tuotteen suunnittelua. Sen kehittyessä minusta tuli yhä levottomampi ja aloin jakaa huoleni esimiehelleni. Kerroin hänelle toistuvasti, että mallit eivät olleet ”puhtaita” ja että niiden pitäisi olla ”kauniita” tavalla, jolla Dijkstran mallit olivat kauniita. Hän ei pitänyt tätä hyödyllisenä kommenttina.Hän muistutti minua siitä, että olimme insinöörejä, emme taiteilijoita. Hänen mielessään ilmaisin yksinkertaisesti makuni ja hän halusi tietää, mitä kriteeriä käytin arvioidessani. En pystynyt kertomaan hänelle! Koska en voinut selittää, mitä periaatteita rikottiin, kommenttini jätettiin yksinkertaisesti huomiotta ja työ jatkui. Aistien, että “makullani” täytyy olla tapa selittää ja antaa motivaatiota, aloin yrittää löytää periaatteen, joka erottaisi hyvät mallit huonoista. Insinöörit ovat hyvin käytännöllisiä; he voivat ihailla kauneutta, mutta he etsivät hyödyllisyyttä. Yritin löytää selityksen miksi ”kauneudesta” oli hyötyä.

Katso loput täältä .

kommentit

• Koska @mlvljr ' -viestin linkki on rikki , tässä on linkki Google-kirjojen sivulle: books.google.co.in/…
• @balajeerc Kiitos (Korjasin myös linkin, joten se osoittaa saman PDF-tiedoston Springer-isännöityyn versioon) 🙂

Luonnollisen koodin laatukriteerejä lukuun ottamatta (vähimmäiskopio / liitä, ei spagettia jne.) hyvän teollisuuskoodin tulisi aina näyttää hieman naiivilta, hieman liian verbokselta, kuten

int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i; 

toisin kuin

Record r = cache.get(i++, false); 

kommentit

• Tarkoittaa kuitenkin do_not_create = false ”pass false argumenttina do_not_create niin, että se luodaan ”tai„ pas s false argumenttina do_create, jotta sitä ei luoda ”? Kielellä, jossa voit käyttää argumenttien nimiä, pidän parempana cache.get (key:i, create: false); i += 1;.

Menen vain ”ylläpidettävän” kanssa

Kaikki koodit on ylläpidettävä: tehtävää ei tarvitse vaikeuttaa kuin on välttämätöntä

Jos joku lukija ei ymmärrä tätä yksinkertaista vaatimusta tai tarvitsee sitä täsmennetyksi, kyseisen lukijan ei pitäisi kirjoittaa koodia …

Hyvä koodi tulee olemaan erilainen jokaiselle henkilölle, ja kielellä, jota he työskentelevät, on myös vaikutus siihen, mitä voidaan pitää olla hyvä koodi. Yleensä lähestyessäni projektia etsin seuraavia asioita:

• Miten projekti organisoidaan? Järjestetäänkö lähdetiedostot puhtaalla tavalla ja voinko löytää koodin liian suurella vaivalla?
• Kuinka koodi on järjestetty? Onko dokumentoitu selvästi, mitä tiedoston koodi tekee, esimerkiksi käyttämällä tiedostotunnistetta tai käyttämällä jokaista omassa tiedostossaan olevaa luokkaa? Onko tiedostossa toimintoja, joita ei enää käytetä sovelluksessa?
• Kuinka toiminnot on järjestetty? Onko muuttujien ilmoittamiselle selkeä malli vai onko se melko satunnainen malli? Onko koodilla looginen kulku siihen ja välttääkö tarpeettomia ohjausrakenteita? Onko kaikki selvästi dokumentoitu, kun koodi on itse dokumentoitava tarpeen mukaan, ja kommentit ilmaisevat selvästi miksi ja / tai miten koodi toimii?

Kaiken tämän lisäksi tekee sovelluksella on järkevää kokonaisuutena? Sovelluksessa oleva koodi voi olla maailman paras, mutta voi silti olla tuskallista työskennellä, jos sovelluksen kokonaisrakenteella ei ole mitään järkeä.

Haluan olla eri mieltä luettavuudesta. Ei, ei täysin: Hyvän koodin tulisi olla luettavissa, ja se voidaan helposti saavuttaa riittävillä kommenteilla.

Ensinnäkin, mutta on todella kekseliäs ratkaisu kovaan ongelmaan. Toista ei pidä laskea WTF-mittariin, ja se voidaan välttää kommenteilla.

Erittäin luettava koodi voi olla hyvin, hyvin hidas . Vähemmän luettavissa oleva ratkaisu voi parantaa nopeutta moninkertaisesti. R on hieno esimerkki kielestä, jossa se on usein totta. Yksi haluaa välttää silmukoita siellä mahdollisimman paljon.Yleisesti ottaen pidän nopeinta koodia parempana, vaikka se on vähemmän luettavissa. Toisin sanoen, jos parannus on merkittävää kurssin ulkopuolella, ja siihen lisätään tarpeeksi kommentteja selittämään, mitä koodi tekee.

Vielä enemmän, muistinhallinta voi olla ratkaisevan tärkeää monissa tieteellisissä sovelluksissa. Koodi, joka on hyvin luettavissa, on yleensä melko huolimaton muistin käytössä: objekteja on vain enemmän. Usein älykäs muistin käyttö tekee koodista taas vähemmän luettavan. Mutta jos taistelet esimerkiksi gigatavujen DNA-sekvenssien ympärillä, muisti on ratkaiseva tekijä. Jälleen katson, että vähemmän muistia kuluttava koodi on parempi koodi luettavuudesta riippumatta.

Joten kyllä, luettavuus on tärkeää hyvän koodin kannalta. Tiedän Uwe Liggisin annoksen: Ajattelu sattuu ja tietokoneet ovat halpoja. Mutta omalla alallani (tilastollinen genomiikka) viikon laskenta-aikoja ja yli 40 Gb: n muistin käyttöä ei pidetä epänormaalina. Joten kaksinkertaisen nopeuden ja puolen muistin parantaminen on paljon enemmän kuin tämä ylimääräinen luettavuus.

Kommentit

• Ei sääntöä / sääntöjä poikkeuksetta
• Haluan olla eri mieltä erimielisyydestäsi: sanot, että kentälläsi nopeus on erittäin tärkeää ja sanot sen olevan tärkeämpää kuin luettavuus. Olen eri mieltä, sinun pitäisi pyrkiä käyttämään oikeaa tasapainoa. Jos nopeutta ei tarvita, esimerkiksi korkean tason käyttöliittymälle, saatat mieluummin pitää jotain helppohoitoista, jos nopeutta tarvitaan, olen samaa mieltä kanssasi. Tiukkojen sääntöjen sijaan on parempi käyttää tervettä järkeä ja välttää joka tapauksessa ennenaikaista optimointia.
• @BlueTrin Miksi ei molemmat aivot koota nuo hi-perf-lähdekoodit ja dokumentoi myös helvetti mitä ' siellä (kommenteissa)?

Sikäli kuin minusta menee … Tiedän, että kirjoitan hyvää koodia, kun työtoveri, joka työskentelee toisessa projektissa, tulee mukaan ja pystyy hyppäämään sisään ja ymmärtämään, mitä teen, ilman että menen läpi jokaisen lohkon koodin ja näyttää, mitä se tekee.
Sen sijaan, että hän sanoisi: ”Odota hetki, mitä ?!” Hän sanoo: ”Voi, ok, ymmärrän, mitä teit siellä.” Rivit, kun kirjoitat sitä samalla sanot itsellesi: ”Tiedän, että tämä ei ole hyvä tapa tehdä se, mutta minun täytyy vain tehdä se tällä tavalla tällä hetkellä. Muistutan itseäni parantamaan sitä myöhemmin … ”

” Hyvää ”koodia on paljon , mutta tärkeimmät, IMHO, ovat luettavuus ja ylläpidettävyys.

Koodisi sisältää vikoja, todennäköisesti laajennetaan ja käytetään uudelleen ja pitäisi jossain vaiheessa uudelleen harkita – vaikka vierailisitkin siellä uudelleen, on todennäköistä, että sinulla ei ole aavistustakaan mitä helvettiä aluksi teit, tehdä itsellesi palvelus ja älä aseta mitään esteitä tielle.

Varmista, että käytät sitä monimutkaista mutta silti uber-tehokasta algoritmia, mutta varmista, että vietät vähän ylimääräistä aikaa sen dokumentointiin, mutta tee muuten koodi on selkeä ja johdonmukainen.