Mēs visi to esam izdarījuši: saķēruši sīkfailu, kad mamma nemeklēja, vakariņās iedzērusi mazliet par daudz vīna, pēc skaitītāja derīguma beigām ļaujot automašīnai sēdēt stāvvietā. Mēs pat esam mazliet apsteiguši Deadman's Curve. Jā, mēs visi esam pārkāpuši jebkuru no galvenajiem programmēšanas noteikumiem, tie, par kuriem visi piekrīt, ir slikti. Un mums tas slepeni patika.
Mēs esam pielikuši degunu labas programmēšanas noteikumiem, ierakstījuši pilnīgi sliktu kodu - un mēs esam dzīvojuši. No programmēšanas dieviem nebija zibens. Mūsu galddatori nesprāga. Patiesībā mūsu kods tika sastādīts un nosūtīts, un klienti šķita pietiekami laimīgi.
Tas ir tāpēc, ka slikta programmēšana nav tajā pašā līgā, kā, piemēram, laizīt elektrisko žogu vai vilkt tīģerim asti. Lielāko daļu laika tas izdodas. Noteikumi biežāk ir vadlīnijas vai stilistiski ieteikumi, nevis stingras un ātras direktīvas, kuras jāievēro, vai sekos koda nāve. Protams, jūsu kods var tikt izsmiets, iespējams, pat publiski. Bet fakts, ka jūs piekrītat konvencijām, nedaudz aizrauj to, ka pat netīši tiek sagrauts tas, kas ir (biežāk nekā nē) patīkama koda sociālā puse.
Lai padarītu situāciju sarežģītāku, dažreiz labāk ir pārkāpt noteikumus. (Šššš!) Kods iznāk tīrāks. Tas var būt pat ātrāks un vienkāršāks. Noteikumi parasti ir mazliet par plašu, un izveicīgs programmētājs var uzlabot kodu, tos pārkāpjot. Nestāstiet priekšniekam, bet dažreiz ir jēga kodēt savu ceļu.
Tālāk ir saraksts ar deviņiem noteikumiem, kurus daži var uzskatīt par nepieļaujamiem, taču daudzi no mums bieži pārkāpj gan ar panākumiem, gan prieku.
Slikts programmēšanas ieradums Nr. 1: kopēšana
Tas ir nepareizi to darīt skolā. Darbā noteikumi nav tik skaidri. Noteikti ir daži koda bloki, kurus nevajadzētu nozagt. Ja tas nāk no patentēta koda, nelieciet to savā kaudzē, it īpaši, ja tas ir atzīmēts ar autortiesību ziņojumu. Uzrakstiet savu versiju. Tas ir tas, ko viņi jums maksā.
Viltīgāks jautājums rodas, kad sākotnējais radītājs vēlas dalīties. Varbūt tas atrodas vienā no šiem tiešsaistes programmēšanas forumiem. Iespējams, tas ir atvērtā koda kods ar licenci (BSD, MIT), kas ļauj piesaistīt funkciju vai trīs. Nav juridiska iemesla, kas jūs apturētu. Jums maksā par problēmu risināšanu, nevis riteņa izgudrošanu no jauna.
Pārsvarā kopēšanas priekšrocības ir pārliecinošas, un trūkumus var ierobežot ar nelielu rūpību. Kodam, ko saņemat no cienījama avota, jau ir piemērots vismaz viens domāšanas veids. Sākotnējais autors meklēja risinājumu un kaut ko atrada. Cilpas invariants un datu plūsma ir izstrādāta.
Sarežģītie jautājumi ir par to, vai ir kādas nepamatotas kļūdas vai dažādi pieņēmumi par lomu vai pamatā esošajiem datiem. Varbūt jūsu kods sajaucas ar nulles rādītājiem, kamēr sākotnējais kods tos nekad nav pārbaudījis. Ja jūs varat novērst problēmas, tas ir tāpat kā jūsu boss saņem informāciju no diviem programmētājiem. Tā ir pāru programmēšana bez izsmalcinātiem galdiem.
Slikts programmēšanas ieradums Nr. 2: nefunkcionāls kods
Apmēram pēdējās desmitgades laikā funkcionālā paradigma ir augusi. Acolytes, lai izveidotu jūsu programmu no ligzdotās funkcijas, aicina mīlēt citēt pētījumus, kas parāda, kā kods ir drošāks un bez kļūdām nekā vecāks mainīgo un cilpu stils, kas viss ir savilkts kopā neatkarīgi no tā, kā programmētājs priecājas. Bhaktas runā ar patiesu ticīgo dedzību, pārmeklējot nefunkcionālas pieejas kodeksa pārskatīšanā un pieprasījumos. Viņiem pat var būt taisnība attiecībā uz priekšrocībām.
Bet dažreiz jums vienkārši jāizkļūst no līmlentes ruļļa. Brīnišķīgi izstrādāts un graciozi izplānots kods prasa laiku, ne tikai iedomāties, bet arī izveidot un vēlāk orientēties. Visi šie slāņi papildina sarežģītību, un sarežģītība ir dārga. Skaista funkcionāla koda izstrādātājiem ir jāplāno uz priekšu un jānodrošina, ka visi dati tiek nodoti pa pareiziem ceļiem. Dažreiz ir vienkārši vieglāk sasniegt un mainīt mainīgo. Varbūt ievietojiet komentāru, lai to izskaidrotu. Pat pievienojot komentāros garu, greznu atvainošanos nākamajām paaudzēm, ir ātrāk nekā visu sistēmu pārbūvēt, lai to izdarītu pareizi.
Slikts programmēšanas ieradums Nr. 3: nestandarta atstarpes
Lielākā daļa programmatūras atstarpju neietekmē programmas darbību. Izņemot dažas valodas, piemēram, Python, kuras koda bloku norādīšanai izmanto atstarpes, lielākajai daļai atstarpju nav nekādas ietekmes uz programmas uzvedību. Tomēr joprojām ir obsesīvi programmētāji, kuri viņus skaita un uzstāj, ka viņiem ir nozīme. Kāds no viņiem reiz manam priekšniekam visnopietnākajā tonī teica, ka es rakstu “Nestandarta kodu”, un viņš to var redzēt uzreiz. Mans grēks? Pārkāpjot kārtulu ESLint space-infix-ops, neizdarot atstarpi vienādības zīmes abās pusēs.
Dažreiz jums vienkārši jādomā par kaut ko dziļāku nekā atstarpju izvietojums. Varbūt jūs uztraucaties par datu bāzes pārslodzi. Varbūt jūs uztraucaties par to, kā nulles rādītājs var avarēt jūsu kodu. Gandrīz jebkura koda daļa ir svarīgāka par atstarpēm, pat ja neskaidras, priekšnieku standartu komitejas ir aizpildījušas noteikumu lapas par šo atstarpju vai cilņu izvietojumu.
Pārsteidzoši ir tas, ka ir vairāki labi rīki, kas automātiski pārformatē jūsu kodu, lai ievērotu visus precīzi definētos savārstīšanas noteikumus. Cilvēkiem nav jāpavada laiks, domājot par to. Ja tas ir tik svarīgi, viņi to var palaist, izmantojot rīku, lai novērstu problēmu.
Slikts programmēšanas ieradums Nr. 4: Izmantojot iet uz
Lietošanas aizliegums iet uz datumi ar laikmetu, pirms daudzi strukturētas programmēšanas rīki vispār pastāvēja. Ja programmētāji vēlētos izveidot cilpu vai pāriet uz citu rutīnu, viņiem vajadzētu rakstīt IET UZ seko rindas numurs. Pēc dažiem gadiem kompilatoru komandas ļāva programmētājiem līnijas numura vietā izmantot virknes etiķeti. Toreiz tas tika uzskatīts par jaunu aktuālu funkciju.
Daži rezultātu nosauca par “spageti kodu”. Nevienam nebija iespējams vēlāk izlasīt jūsu kodu un sekot izpildes ceļam. Tas bija pavedienu juceklis, mūžīgi samudžināts. Edsgers Dijkstra aizliedza komandu ar drukātu rokrakstu ar nosaukumu “Goto paziņojums uzskatāms par kaitīgu”.
Bet absolūtā sazarošana nav problēma. Tas ir juceklis, kas rodas. Bieži vien izveicīgs pārtraukums vai atgriešanās piedāvās ļoti skaidru paziņojumu par to, ko kods dara šajā vietā. Dažreiz pievienojot iet uz Lietas izklāstā tiks izveidots kaut kas vienkāršāk saprotams nekā pareizi strukturēts kaskādes bloku saraksts.
Ir pretpiemēri. Apple SSL steka drošības caurums “goto fail” ir viens no labākajiem gadījumiem. Bet, ja mēs esam uzmanīgi, lai izvairītos no dažiem gadījuma paziņojumiem un cilpām, mēs varam ievietot labus, absolūtus lēcienus, kas lasītājam atvieglo notiekošā izpratni. Mēs varam ielikt a pārtraukums vai a atgriešanās tas ir tīrāks un patīkamāks visiem, izņemot varbūt iet uz nīdēji.
Slikts programmēšanas ieradums Nr. 5: nedeklarē tipus
Cilvēkiem, kuri mīl drukātas valodas, ir jēga. Mēs pievienojam labāku, bez kļūdām kodu, kad pievienojam skaidras katra mainīgā datu tipa deklarācijas. Brīdī, kad pauzē tipa izpausmi, kompilators atzīmē stulbas kļūdas, pirms kods sāk darboties. Tas var būt sāpes, bet tas palīdz. Tā ir jostu un bikšturu pieeja programmēšanai, kas novērš kļūdas.
Laiki ir mainījušies. Daudzi jaunākie kompilatori ir pietiekami gudri, lai secinātu veidu, aplūkojot kodu. Viņi var strādāt atpakaļ un uz priekšu, izmantojot kodu, līdz viņi var būt pārliecināti, ka mainīgajam jābūt a virkne vai an int vai kaut kas cits. Un, ja šie izsecinātie veidi nav rindā, tad sastādītāji var izvirzīt kļūdas karodziņu. Viņiem vairs nav nepieciešams, lai mēs vairāk ievadītu mainīgos.
Tas nozīmē, ka tagad ir vieglāk ietaupīt dažus bitus, neatstājot dažas no vienkāršākajām deklarācijām. Kods kļūst mazliet tīrāks, un lasītājs parasti ir diezgan spējīgs uzminēt, ka mainīgais nosaukts i in for cilpa ir vesels skaitlis.
Slikts programmēšanas ieradums Nr. 6: Yo-yo kods
Programmētāji to labprāt sauc par “yo-yo kodu”. Vispirms vērtības tiek saglabātas kā virknes. Tad tos parsē veselos skaitļos. Tad viņi atkal tiek pārveidoti par stīgām. Tas ir šausmīgi neefektīvi. Jūs varat gandrīz sajust CPU cīņu ar visu papildu slodzi. Gudri programmētāji, kuri ātri raksta kodu, izstrādā savas arhitektūras, lai samazinātu reklāmguvumu skaitu. Viņu kods darbojas ātrāk viņu plānošanas dēļ.
Bet ticiet vai nē, bet dažreiz tam ir jēga. Dažreiz jums ir burzma-bibliotēka, kas savā patentētajā melnajā kastē dara daudz gudru lietu. Dažreiz priekšnieks uzrakstīja septiņciparu čeku, lai licencētu visu ģēniju tajā melnajā kastē. Ja bibliotēka vēlas datus virknēs, jūs tos piešķirat bibliotēkai virknēs, pat ja nesen tos konvertējāt veselos skaitļos.
Protams, jūs varētu pārrakstīt visu kodu, lai samazinātu reklāmguvumu, taču tas prasītu laiku. Dažreiz ir pareizi, ja kods izpilda papildu minūti, stundu, dienu vai pat nedēļu, jo koda pārrakstīšana prasītu vēl vairāk laika. Dažreiz tehniskā parāda palielināšanās ir lētāka nekā sākotnēji pareiza veidošana.
Dažreiz bibliotēka nav patentēts kods, bet kods, kuru pats esat uzrakstījis pats. Dažreiz ir ātrāk konvertēt datus vēl vienu reizi, nekā pārrakstīt visu šajā bibliotēkā. Tātad jūs ejat līdzi un jūs rakstāt yo-yo kodu. Viss kārtībā - mēs visi tur esam bijuši.
Slikts programmēšanas ieradums Nr. 7: savu datu struktūru rakstīšana
Viens no standarta noteikumiem ir tāds, ka programmētājam nekad nav jāraksta kods datu glabāšanai pēc datu struktūras kursa pabeigšanas otrajā gadā. Kāds cits jau ir uzrakstījis visas datu struktūras, kas mums jebkad būs nepieciešamas, un viņu kods gadu gaitā ir pārbaudīts un atkārtoti pārbaudīts. Tas ir saistīts ar valodu, un, iespējams, tas ir bez maksas. Jūsu kodā varēja būt tikai kļūdas.
Bet dažreiz datu struktūras bibliotēkas ir nedaudz lēnas. Dažreiz viņi mūs piespiež struktūrā, kas var būt standarta, bet nepareiza mūsu kodam. Dažreiz bibliotēkas mūs mudina pārkonfigurēt datus pirms struktūras izmantošanas. Dažreiz bibliotēkās ir siksnu un bikšturu aizsardzība ar tādām funkcijām kā vītņu bloķēšana, un mūsu kodam tās nav vajadzīgas.
Kad tas notiks, ir pienācis laiks uzrakstīt savas datu struktūras. Dažreiz tas notiek daudz, daudz ātrāk. Dažreiz tas padara mūsu kodu daudz tīrāku, jo mēs neiekļaujam visu papildu kodu, lai precīzi formatētu datus.
Slikts programmēšanas ieradums Nr. 8: vecmodīgas cilpas
Jau sen kāds, kurš izveidoja C valodu, vēlējās visas abstraktās iespējas apvienot vienā vienkāršā konstrukcijā. Sākumā bija jāizdara dažas lietas, dažas lietas, kas jādara katru reizi, izmantojot cilpu, un kāds veids, kā pateikt, kad tas viss ir izdarīts. Toreiz tā šķita pilnīgi tīra sintakse bezgalīgu iespēju uztveršanai.
Tas bija toreiz. Tagad daži mūsdienu rājieni redz tikai nepatikšanas. Notiek pārāk daudz lietu. Visas šīs labestības iespējas ir vienlīdz spējīgas arī uz sliktumu. Tas padara lasīšanu un grokošanu daudz grūtāku. Viņiem patīk funkcionālāka paradigma, kurā nav cilpu, tikai funkcijas, kas piemērotas sarakstiem, skaitļošanas veidnes, kas sakārtotas dažiem datiem.
Ir gadījumi, kad bezcilpas veids ir tīrāks, it īpaši, ja ir tikai viena kārtīga funkcija un masīvs. Bet ir gadījumi, kad vecmodīgā cilpa ir daudz vienkāršāka, jo tā var daudz vairāk. Piemēram, pirmās atbilstības meklēšana ir vienkāršāka, kad varat pārtraukt, tiklīdz tā ir atrasta.
Turklāt kartēšanas funkcijas veicina sloppier kodēšanu, ja datiem ir jādara vairākas lietas. Iedomājieties, ka vēlaties ņemt katra skaitļa absolūto vērtību un pēc tam kvadrātsakni. Ātrākais risinājums ir pirmās un pēc tam otrās funkcijas kartēšana, divreiz pārslēdzot datus.
Slikts programmēšanas ieradums Nr. 9: Izlaušanās no cilpām vidū
Kaut kur pa līniju noteikumu veidošanas grupa paziņoja, ka katrai cilpai jābūt “nemainīgai”, tas ir, loģiskam apgalvojumam, kas ir taisnība visā ciklā. Kad invariants vairs nav taisnība, cilpa beidzas. Tas ir labs veids, kā domāt par sarežģītām cilpām, taču tas noved pie trakiem aizliegumiem, piemēram, aizliedz mums izmantot a atgriešanās vai a pārtraukums cilpas vidū. Šī ir aizliegto noteikumu apakškopa iet uz paziņojumi.
Šī teorija ir laba, taču parasti tā noved pie sarežģītāka koda. Apsveriet šo vienkāršo gadījumu, kas skenē masīvu vienam ierakstam, kas iztur pārbaudi:
kamēr es<>...
ja (tests (a [i]), tad atgrieziet a [i];
...
}
Cilpas nemainīgie cienītāji labprātāk pievienotu vēl vienu Būla mainīgo, to saucam nav atrastsun izmantojiet to šādi:
kamēr ((notFound) && (i<>...
ja (tests (a [i])), tad notFound = false;
...
}
Ja šis būla skaitlis ir labi nosaukts, tas ir lielisks pašdokumentējoša koda gabals. Tas var atvieglot ikviena cilvēka izpratni. Bet tas arī papildina sarežģītību. Un tas nozīmē piešķirt citu lokālo mainīgo un aizsprostot reģistru, kuru kompilators var būt vai nav pietiekami gudrs, lai to labotu.
Dažreiz a iet uz vai lēciens ir tīrāks.
Slikts programmēšanas ieradums Nr. 10: operatoru un funkciju pārdefinēšana
Dažas no visjautrākajām valodām ļauj jums izdarīt patiesi viltīgas lietas, piemēram, no jauna noteikt tādu elementu vērtību, kuri izskatās nemainīgi. Piemēram, Python ļauj rakstīt PATIESA = FALSE, vismaz versijā 2.7 un iepriekš. Tas nerada kaut kādu loģikas sabrukumu un Visuma beigas; tas vienkārši maina PATIESA un FALSE. Šādas bīstamas spēles varat spēlēt arī ar C priekšapstrādātājiem un dažām citām valodām. Vēl citas valodas ļauj no jauna definēt operatorus, piemēram, plus zīmi.
Tas ir posms, taču lielā koda blokā būs punkti, kad būs ātrāk no jauna definēt vienu vai vairākas no šīm tā sauktajām konstantēm. Dažreiz priekšnieks vēlas, lai kods darītu pilnīgi atšķirīgu. Protams, jūs varētu izpētīt kodu un mainīt katru gadījumu, vai arī jūs varētu no jauna definēt realitāti. Tas var likt jums izskatīties kā ģēnijam. Tā vietā, lai pārrakstītu milzīgu bibliotēku, jūs vienkārši mazliet pavērsieties, un tas notiek tieši pretēji.
Varbūt šeit ir labi novilkt robežu. Jums to nevajadzētu izmēģināt mājās neatkarīgi no tā, cik gudrs un jautrs tas var būt. Tas ir pārāk bīstami - tiešām ... godīgi.
