Programavimas

10 blogų programavimo įpročių, kuriuos slapta mėgstame

Mes visi tai padarėme: užsitraukėme sausainį, kai mama neieškojo, pavalgėme šiek tiek per daug vyno, vakarienei leidome mašiną atsisėsti, pasibaigus skaitiklio galiojimo laikui. Mes netgi perėjome Deadman's Curve šiek tiek per greitai. Ir taip, mes visi pažeidėme bet kokį skaičių pagrindinių programavimo taisyklių, tų, kurias visi sutinka, yra blogai. Ir mums tai slapta patiko.

Mes užkišome nosį dėl gero programavimo taisyklių, išspausdinome kodą, kuris yra visiškai blogas - ir mes gyvenome. Programavimo dievų žaibų nebuvo. Mūsų darbalaukiai nesprogo. Tiesą sakant, mūsų kodas buvo sudarytas ir išsiųstas, o klientai atrodė pakankamai patenkinti.

Taip yra todėl, kad blogas programavimas nėra toje pačioje lygoje, kaip, tarkime, elektrinės tvoros laižymas ar tigro uodegos traukimas. Dažniausiai tai pasiteisina. Taisyklės dažniau yra gairės ar stilistiniai pasiūlymai, o ne griežtos instrukcijos, kurių reikia laikytis, arba bus laikomasi mirties. Žinoma, jūsų kodas gali būti išjuoktas, galbūt net viešai. Tačiau tai, kad jūs laikotės susitarimų, prideda šiek tiek jaudulio, net netyčia sumenkindami tai, kas yra (dažniausiai ar ne) socialiniai malonaus kodo papročiai.

Kad būtų sudėtingiau, kartais geriau pažeisti taisykles. (Šššš!) Kodas išeina švaresnis. Tai gali būti net greitesnė ir paprastesnė. Taisyklės paprastai yra šiek tiek per plačios, o sumanus programuotojas gali patobulinti kodą jas sulaužydamas. Nesakykite savo viršininkui, bet kartais yra prasmė koduoti savo kelią.

Toliau pateikiamas devynių taisyklių sąrašas, kurių kai kurie gali laikyti neprieštaraujančiais, tačiau daugelis iš mūsų dažnai laužo ir su sėkme, ir su malonumu.

Blogas programavimo įprotis Nr. 1: kopijavimas

Neteisinga tai daryti mokykloje. Darbe taisyklės nėra tokios aiškios. Tikrai yra keletas kodų blokų, kurių nereikėtų pavogti. Jei jis gaunamas iš patentuoto kodo, nesudėkite jo į savo kaupą, ypač jei jis pažymėtas autorių teisių pranešimu. Parašykite savo versiją. Tai, ką jie tau moka.

Keblesnis klausimas kyla tada, kai originalus kūrėjas nori pasidalinti. Galbūt tai yra viename iš tų internetinių programavimo forumų. Galbūt tai yra atvirojo kodo kodas su licencija (BSD, MIT), leidžiantis užfiksuoti funkciją ar tris. Nėra jokios teisinės priežasties, kuri jus sustabdytų. Jums mokama už problemų sprendimą, o ne iš naujo išradimą.

Dažniausiai kopijavimo privalumai yra įtikinami, o trūkumus galima šiek tiek atsargiai apriboti. Kodas, kurį gaunate iš patikimo šaltinio, jau pritaikė bent vieną mintį. Originalus autorius ieškojo sprendimo ir kažką rado. Buvo parengti kilpų invariantai ir duomenų srautas.

Keblus klausimas - ar yra kokių nors nepagrįstų klaidų, ar kitokių prielaidų apie vaidmenį ar pagrindinius duomenis. Galbūt jūsų kodas susimaišo į niekines nuorodas, o originalus kodas jų niekada netikrino. Jei galite išspręsti problemas, jūsų bosas gauna dviejų programuotojų indėlį. Tai porinis programavimas be puošnių stalų.

Blogas programavimo įprotis Nr. 2: nefunkcinis kodas

Maždaug pastarąjį dešimtmetį funkcinė paradigma kilo į viršų. Akolytės, skirtos jūsų programai kurti iš įdėtos funkcijos, reiškia meilę cituoti tyrimus, rodančius, kaip kodas yra saugesnis ir be klaidų nei senesnis kintamųjų ir kilpų stilius, visi sujungti bet kokiu būdu, kad programuotojas būtų laimingas. Bhaktos kalba su tikrų tikinčiųjų uolumu, gaudydamos nefunkcionalius metodus, peržiūrėdamos kodeksą ir pateikdamos prašymus. Jie netgi gali būti teisūs dėl pranašumų.

Tačiau kartais jums tiesiog reikia išimti lipnios juostos ritinį. Nuostabiai sukonstruotas ir grakščiai suplanuotas kodas reikalauja laiko ne tik įsivaizduoti, bet ir sukonstruoti bei vėliau naršyti. Visi šie sluoksniai suteikia sudėtingumo, o sudėtingumas yra brangus. Gražaus funkcinio kodo kūrėjai turi planuoti iš anksto ir užtikrinti, kad visi duomenys būtų perduodami tinkamais keliais. Kartais paprasčiau pasiekti ir pakeisti kintamąjį. Gal įdėk komentarą, kad tai paaiškintum. Netgi komentare pridėjus ilgą, žiaurų atsiprašymą ateities kartoms, greičiau nei iš naujo sukonstruoti visą sistemą, kad tai būtų daroma teisingai.

Netinkamas programavimo įprotis Nr. 3: nestandartiniai tarpai

Dauguma programinės įrangos vietų neturi įtakos programos veikimui. Išskyrus kelias kalbas, tokias kaip „Python“, kurios tarpais naudoja kodo blokus, dauguma tarpų neturi jokio poveikio programos elgsenai. Vis dėlto yra įkyrių programuotojų, kurie juos skaičiuoja ir reikalauja, kad jie būtų svarbūs. Vienas iš jų mano viršininkui rimčiausiu tonu kartą pasakė, kad rašau „Nestandartinį kodą“, ir jis tai galėjo iškart pamatyti. Mano nuodėmė? Pažeidus „ESLint space-infix-ops“ taisyklę, nepadėjus tarpo iš abiejų lygybės ženklo pusių.

Kartais jūs tiesiog turite galvoti apie kažką giliau nei erdvių išdėstymas. Gal jūs nerimaujate, kad duomenų bazė bus perkrauta. Galbūt nerimaujate dėl kokio nors būdo, kai nulinis žymeklis gali sugadinti jūsų kodą. Bet kuri kodo dalis yra svarbesnė nei tarpai, net jei nesudėtingi, viršininkų standartų komitetai užpildė taisyklių puslapius apie šių tarpų ar skirtukų išdėstymą.

Nuostabu tai, kad yra keletas gerų įrankių, kurie automatiškai performatuos jūsų kodą, kad būtų laikomasi bet kokių gerai apibrėžtų pūkavimo taisyklių. Žmonėms nereikia skirti laiko galvojant apie tai. Jei tai taip svarbu, jie gali ją paleisti per įrankį, kad išvalytų problemą.

Blogas programavimo įprotis Nr. 4: Naudojimas eiti į

Draudimas naudoti eiti į prasidėjo dar prieš struktūrinio programavimo įrankių egzistavimą. Jei programuotojai norėtų sukurti kilpą ar pereiti prie kitos tvarkos, jie turėtų įvesti tekstą EITI Į po kurio eina eilutės numeris. Po kelerių metų kompiliatorių komandos leido programuotojams vietoj eilutės numerio naudoti eilutės etiketę. Tada tai buvo laikoma nauja karšta funkcija.

Kai kurie rezultatą pavadino „spagečių kodu“. Vėliau niekam buvo neįmanoma perskaityti jūsų kodo ir eiti vykdymo keliu. Tai buvo amžinai susivėlęs siūlų kratinys. Edsgeris Dijkstra uždraudė komandą su rankraščiu, pavadintu „Goto pareiškimas laikomas žalingu“.

Tačiau absoliutus išsišakojimas nėra problema. Tai rezultatas. Dažnai sumanus pertrauka arba grįžti pasiūlys labai švarų teiginį apie tai, ką kodas veikia toje vietoje. Kartais pridedant eiti į į atvejo pareiškimą bus lengviau suprasti, nei tinkamai sukonstruotas kaskadinių „jei-tada-dar“ blokų sąrašas.

Yra ir pavyzdžių. „Goto fail“ saugumo skylė „Apple SSL stack“ yra vienas geriausių atvejų. Bet jei mes atsargūs, kad išvengtume kai kurių problemų pavyzdžių ir kilpų, galime įterpti gerus, absoliučius šuolius, kurie skaitytojui lengviau suprasti, kas vyksta. Mes galime įdėti a pertrauka arba a grįžti tai yra švariau ir maloniau visiems, išskyrus galbūt eiti į neapykantos.

Blogas programavimo įprotis Nr. 5: tipų nedeklaravimas

Žmonės, kurie mėgsta spausdintas kalbas, turi tašką. Mes rašome geresnį, be klaidų kodą, kai pridedame aiškias kiekvieno kintamojo duomenų tipo deklaracijas. Akimirkos sustabdymas norint išsiaiškinti tipą, padeda kompiliatoriui pažymėti kvailas klaidas prieš pradedant vykdyti kodą. Tai gali būti skausmas, bet jis padeda. Tai klaidų sustabdantis diržų ir petnešėlių požiūris į programavimą.

Laikai pasikeitė. Daugelis naujesnių kompiliatorių yra pakankamai protingi, kad galėtų padaryti išvadą apie tipą, žiūrėdami į kodą. Jie gali dirbti atgal ir pirmyn per kodą, kol galės įsitikinti, kad kintamasis turi būti a stygos arba an tarpt ar kažkas kita. Ir jei šie išvardyti tipai nesirikiuotų, kompiliatoriai gali iškelti klaidų žymą. Jiems nereikia, kad mes daugiau įvestume kintamuosius.

Tai reiškia, kad dabar lengviau sutaupyti keletą bitų, paliekant keletą paprasčiausių deklaracijų. Kodas tampa šiek tiek švaresnis, ir skaitytojas paprastai sugeba atspėti, kad kintamasis įvardytas i „for“ kilpa yra sveikasis skaičius.

Blogas programavimo įprotis Nr. 6: Yo-yo kodas

Programuotojai mėgsta tai vadinti „yo-yo kodu“. Pirmiausia reikšmės saugomos kaip eilutės. Tada jie suskaidomi į sveikus skaičius. Tada jie vėl paverčiami stygomis. Tai siaubingai neefektyvu. Beveik jaučiate, kaip kova su procesoriumi esant visam papildomam krūviui. Protingi programuotojai, kurie rašo greitą kodą, kuria savo architektūras, kad sumažintų konversijų skaičių. Jų kodas veikia greičiau dėl jų planavimo.

Bet tikėkite tuo ar ne, kartais tai turi prasmę. Kartais turite „whiz-bang“ biblioteką, kuri savo patentuotoje juodojoje dėžutėje daro daugybę protingų dalykų. Kartais bosas išrašydavo septynių skaitmenų čekį, kad licencijuotų visą geniją toje juodojoje dėžutėje. Jei biblioteka nori, kad duomenys būtų eilutės, juos bibliotekai atiduosite eilutėmis, net jei neseniai juos pavertėte sveikaisiais skaičiais.

Žinoma, galite perrašyti visą kodą, kad sumažintumėte konversiją, tačiau tai užtruks. Kartais gerai, kad kodas paleis papildomą minutę, valandą, dieną ar net savaitę, nes kodo perrašymas užtruktų dar daugiau laiko. Kartais susidaryti techninę skolą yra pigiau, nei pirmiausia ją sukurti.

Kartais biblioteka nėra patentuotas kodas, bet kodas, kurį pats parašėte seniai. Kartais greičiau paversti duomenis dar kartą, nei perrašyti viską toje bibliotekoje. Taigi eini kartu ir rašai yo-yo kodą. Viskas gerai - mes visi ten buvome.

Netinkamas programavimo įprotis Nr. 7: rašykite savo duomenų struktūras

Viena iš standartinių taisyklių yra ta, kad programuotojas niekada neturėtų rašyti kodo duomenims saugoti, baigęs duomenų struktūros kursą antrame kurse. Kažkas jau parašė visas mums reikalingas duomenų struktūras, o jų kodas buvo išbandytas ir išbandytas per metus. Ji pridedama prie kalbos ir tikriausiai nemokama. Jūsų kode galėjo būti tik klaidų.

Tačiau kartais duomenų struktūros bibliotekos yra šiek tiek lėtos. Kartais jie priverčia mus į struktūrą, kuri gali būti standartinė, bet neteisinga mūsų kodui. Kartais bibliotekos verčia mus perkonfigūruoti duomenis prieš naudojant struktūrą. Kartais bibliotekose yra diržų ir petnešų apsauga su tokiomis funkcijomis kaip siūlų užrakinimas, o mūsų kodui jų nereikia.

Kai taip atsitiks, atėjo laikas parašyti savo duomenų struktūras. Kartais tai daug, daug greičiau. Kartais tai daro mūsų kodą daug švaresnį, nes neįtraukiame viso papildomo kodo, kad tiksliai suformatuotume duomenis.

Blogas programavimo įprotis Nr. 8: senamadiškos kilpos

Seniai kažkas, sukūręs C kalbą, norėjo visas abstrakčias galimybes apimti viename paprastame konstrukte. Pradžioje buvo keletas dalykų, kuriuos reikia atlikti kiekvieną kartą, ir tam tikru būdu pasakyti, kada viskas buvo padaryta. Tuo metu tai atrodė visiškai švari sintaksė begalinių galimybių fiksavimui.

Tai buvo tada. Dabar kai kurie šiuolaikiniai barniai mato tik bėdą. Yra per daug dalykų. Visos šios gerumo galimybės taip pat vienodai sugeba į blogį. Tai apsunkina skaitymą ir šniokštimą. Jie mėgsta funkcionalesnę paradigmą, kai nėra kilpų, tik funkcijos, taikomos sąrašams, skaičiavimo šablonai, susieti su kai kuriais duomenimis.

Yra atvejų, kai „loopless“ būdas yra švaresnis, ypač kai yra tik viena tvarkinga funkcija ir masyvas. Tačiau yra atvejų, kai senamadiška kilpa yra daug paprastesnė, nes ji gali padaryti daug daugiau. Pavyzdžiui, ieškoti pirmosios atitikties yra paprasčiau, kai galite nustoti, kai tik ją rasite.

Be to, susiejimo funkcijos skatina aplaidesnį kodavimą, kai duomenims reikia atlikti kelis veiksmus. Įsivaizduokite, kad norite imti absoliučią vertę, o tada kiekvieno skaičiaus kvadratinę šaknį. Greičiausias sprendimas yra susieti pirmąją funkciją, o po to - antrąją, du kartus perjungiant duomenis.

Blogas programavimo įprotis Nr. 9: Ištrūkimas iš kilpų viduryje

Kažkur iš eilės taisyklių kūrimo grupė pareiškė, kad kiekviena kilpa turi turėti „nekintamą“, tai yra loginį teiginį, kuris yra teisingas visoje cikle. Kai invariantas nebėra teisingas, ciklas baigiasi. Tai geras būdas galvoti apie sudėtingas kilpas, tačiau tai sukelia beprotiškus draudimus, pavyzdžiui, draudžia mums naudoti a grįžti arba a pertrauka kilpos viduryje. Tai yra draudžiančių taisyklių pogrupis eiti į pareiškimus.

Ši teorija yra puiki, tačiau ji dažniausiai sukelia sudėtingesnį kodą. Apsvarstykite šį paprastą atvejį, kuris nuskaito masyvą vienam įrašui, kuris išlaikė testą:

kol aš<>

   ...

jei (testas (a [i]), tada grąžink a [i];

   ...

}

„Loop invariant“ mėgėjai verčiau pridėsime kitą loginį kintamąjį, vadinsime jį nerastasir naudokite jį taip:

tuo tarpu ((notFound) && (t<>

...

if (testas (a [i])), tada notFound = false;

...

}

Jei ši loginė reikšmė yra gerai pavadinta, tai puikus savidokumentuojantis kodas. Tai gali padėti visiems lengviau suprasti. Tačiau tai taip pat prideda sudėtingumo. Tai reiškia, kad paskiriamas kitas vietinis kintamasis ir užkemšamas registras, kurį kompiliatorius gali arba nėra pakankamai protingas ištaisyti.

Kartais a eiti į ar šuolis švaresnis.

Netinkamas programavimo įprotis Nr. 10: Operatorių ir funkcijų apibrėžimas iš naujo

Kai kurios iš smagiausių kalbų leidžia atlikti tikrai apsukrius dalykus, pvz., Iš naujo apibrėžti elementų, kurie atrodo nuolatiniai, vertę. Pavyzdžiui, „Python“ leidžia įvesti tekstą TIESA = NETIESA, bent jau 2.7 versijoje ir anksčiau. Tai nesukuria kažkokio loginio žlugimo ir visatos pabaigos; ji tiesiog keičiasi reikšme TIESA ir NETIESA. Taip pat galite žaisti tokius pavojingus žaidimus kaip „C“ procesoriai ir kai kurios kitos kalbos. Dar kitos kalbos leidžia iš naujo apibrėžti operatorius, pvz., Pliuso ženklą.

Tai ruožas, tačiau dideliame kodo bloke bus taškų, kai greičiau iš naujo apibrėžti vieną ar daugiau iš šių vadinamųjų konstantų. Kartais bosas nori, kad kodas padarytų visai ką kita. Aišku, galėtumėte išnagrinėti kodą ir pakeisti kiekvieną įvykį arba iš naujo apibrėžti tikrovę. Tai gali priversti jus atrodyti kaip genijus. Užuot perrašę didžiulę biblioteką, jūs tiesiog šiek tiek apverčiate, ir tai daro priešingai.

Galbūt čia gerai nubrėžti ribą. Nereikėtų to išbandyti namuose, kad ir kaip tai būtų protinga ir smagu. Tai yra per daug pavojinga - tikrai ... sąžininga.

$config[zx-auto] not found$config[zx-overlay] not found