Vi har alle gjort det: festet en informasjonskapsel når mor ikke så, hadde litt for mye vin til middag, la bilen sitte på en parkeringsplass etter at måleren var utløpt. Vi har til og med gått rundt Deadman's Curve litt for fort. Og ja, vi har alle brutt noen av hovedreglene for programmering, de som alle er enige om er dårlige. Og vi likte det i hemmelighet.
Vi har tømt nesen vår for reglene for god programmering, skrevet kode som er helt dårlig - og vi har levd. Det var ingen lyn fra programmeringsgudene. Våre stasjonære maskiner eksploderte ikke. Faktisk ble koden vår samlet og sendt, og kundene virket fornøyde nok.
Det er fordi dårlig programmering ikke er i samme liga som for eksempel å slikke et elektrisk gjerde eller trekke halen til en tiger. Mesteparten av tiden ordner det seg. Reglene er oftere retningslinjer eller stilforslag, ikke harde og raske direktiver som må følges, ellers vil kodedød følge. Visst, koden din kan bli latterliggjort, muligens til og med offentlig. Men det faktum at du henter konvensjoner, legger litt spenning til å undergrave, selv uforvarende, det som utgjør (oftere enn ikke) den sosiale moren til hyggelig kode.
For å gjøre saken mer kompleks, er det noen ganger bedre å bryte reglene. (Shhhh!) Koden kommer renere ut. Det kan til og med være raskere og enklere. Reglene er vanligvis litt for brede, og en kunstnerisk programmerer kan forbedre koden ved å bryte dem. Ikke fortell sjefen din, men noen ganger er det fornuftig å kode din egen måte.
Det som følger er en liste over ni regler som noen kan betrakte som uoverkommelige, men mange av oss bryter ofte, med både suksess og glede.
Dårlig programmeringsvaner nr. 1: Kopiering
Det er feil å gjøre det på skolen. På jobben er ikke reglene så klare. Det er absolutt noen kodeblokker som ikke skal bli stjålet. Hvis den kommer fra proprietær kode, må du ikke brette den i bunken din, spesielt hvis den er merket med en copyright-melding. Skriv din egen versjon. Det er hva de betaler deg for å gjøre.
Det vanskeligere spørsmålet kommer når den opprinnelige skaperen vil dele. Kanskje det er på en av disse online programmeringsforaene. Kanskje det er åpen kildekode med en lisens (BSD, MIT) som tillater å fange en funksjon eller tre. Det er ingen lovlig grunn til å stoppe deg. Og du får betalt for å løse problemer, ikke å finne opp hjulet på nytt.
Mesteparten av tiden er fordelene med kopiering overbevisende, og ulempene kan begrenses med litt forsiktighet. Koden du får fra en hederlig kilde har allerede brukt minst en tankeomgang. Den opprinnelige forfatteren lette etter en løsning og fant noe. Loop invarianter og datastrømmen er utarbeidet.
De vanskelige spørsmålene er om det er noen ubegrunnede feil eller noen forskjellige forutsetninger om rollen eller de underliggende dataene. Kanskje blandes koden din i nullpekere mens den opprinnelige koden aldri sjekket dem. Hvis du kan løse problemene, er det som sjefen din får innspill fra to programmerere. Det er parprogrammering uten de fancy skrivebordene.
Dårlig programmeringsvaner nr. 2: Ikke-funksjonell kode
I det siste tiåret har det funksjonelle paradigmet vært stigende. Akolyttene for å bygge programmet ditt ut av nestet funksjon kaller kjærlighet til å sitere studier som viser hvordan koden er tryggere og mer feilfri enn den eldre stilen med variabler og sløyfer, alt sammenkledd på en hvilken som helst måte som gjør programmereren glad. De hengivne snakker med iver fra sanne troende, og tetter ikke-funksjonelle tilnærminger i kodevurderinger og trekker forespørsler. De kan til og med ha rett i fordelene.
Men noen ganger trenger du bare å få ut en rull med tape. Fantastisk konstruert og elegant planlagt kode tar tid, ikke bare å forestille seg, men også å konstruere og senere å navigere. Alle disse lagene tilfører kompleksitet, og kompleksitet er dyrt. Utviklere av vakker funksjonell kode må planlegge fremover og sørge for at alle data blir sendt på riktig vei. Noen ganger er det bare lettere å nå ut og endre en variabel. Kanskje legge inn en kommentar for å forklare det. Selv å legge til en lang, skremmende unnskyldning for fremtidige generasjoner i kommentaren er raskere enn å omarkitekturere hele systemet for å gjøre det på riktig måte.
Dårlig programmeringsvaner nr. 3: Ikke-standardavstand
De fleste mellomrom i programvare har ingen innvirkning på hvordan programmet fungerer. Bortsett fra noen få språk som Python som bruker avstanden for å indikere kodeblokker, har de fleste mellomrom null effekt på hvordan programmet oppfører seg. Likevel er det obsessive programmerere som teller dem og insisterer på at de har betydning. En av dem fortalte en gang sjefen min i den mest alvorlige tonen at jeg skrev "Non Standard Code", og han kunne se det med en gang. Min synd? Brudd på ESLint space-infix-ops-regelen ved å unnlate å plassere et mellomrom på begge sider av et likhetstegn.
Noen ganger må du bare tenke på noe dypere enn plassering av mellomrom. Kanskje du bekymrer deg for at databasen blir overbelastet. Kanskje du bekymrer deg for at en nullpeker kan krasje koden din. Nesten alle deler av koden er viktigere enn mellomrommene, selv om nebbede, sjefete standardkomiteer har fylt sider med regler om plassering av disse mellomrommene eller fanene.
Den fantastiske tingen er at det er flere gode verktøy som automatisk vil formatere koden din for å overholde noen veldefinerte lineregler. Mennesker trenger ikke bruke tid på å tenke på dette. Hvis det er så viktig, kan de kjøre det gjennom verktøyet for å rydde opp i problemet.
Dårlig programmeringsvaner nr. 4: Bruk gå til
Forbudet mot bruk gå til stammer fra tiden før mange av verktøyene for strukturert programmering eksisterte. Hvis programmerere ønsket å lage en løkke eller hoppe til en annen rutine, måtte de skrive GÅ TIL etterfulgt av et linjenummer. Etter noen år lar kompilatorteam programmerere bruke en strengetikett i stedet for et linjenummer. Det ble ansett som en hot ny funksjon den gangen.
Noen kalte resultatet for “spaghettikode”. Det var umulig for noen å lese koden din senere og følge veien for henrettelse. Det var en virvar av virvar, for alltid sammenflettet. Edsger Dijkstra forbød kommandoen med et manuskript med tittelen "Gå til uttalelse ansett som skadelig."
Men absolutt forgrening er ikke problemet. Det er floke som resulterer. Ofte en kunstnerisk gå i stykker eller komme tilbake vil tilby en veldig ren uttalelse om hva koden gjør på det stedet. Noen ganger legger til gå til til en saksuttalelse vil produsere noe som er enklere å forstå enn en mer riktig strukturert liste over cascading if-then-else blokker.
Det er moteksempler. Sikkerhetshullet "goto fail" i Apples SSL-stack er et av de beste tilfellene. Men hvis vi er forsiktige med å unngå noen av de kjipe sakene med saksuttalelser og løkker, kan vi sette inn gode, absolutte hopp som gjør det lettere for leseren å forstå hva som skjer. Vi kan legge inn en gå i stykker eller a komme tilbake det er renere og mer behagelig for alle - bortsett fra kanskje gå til hatere.
Dårlig programmeringsvaner nr. 5: Ikke erklære typer
Folk som elsker maskinskrevne språk har et poeng. Vi skriver bedre, mer feilfri kode når vi legger til tydelige erklæringer om datatypen for hver variabel. Hvis du pauser et øyeblikk for å stave ut typen, hjelper kompilatoren å flagge dumme feil før koden begynner å kjøre. Det kan være vondt, men det hjelper. Det er en belte-og-seler-tilnærming til programmering som stopper feil.
Tidene har endret seg. Mange av de nyere kompilatorene er smarte nok til å utlede typen ved å se på koden. De kan jobbe bakover og fremover gjennom koden til de kan være sikre på at variabelen må være a streng eller en int eller noe annet. Og hvis disse avledede typene ikke stemmer overens, kan kompilatorene heve et feilflagg. De trenger ikke at vi skal skrive variablene lenger.
Dette betyr at det nå er enklere å lagre noen få biter ved å gi fra seg noen av de enkleste erklæringene. Koden blir litt renere, og leseren er vanligvis ganske i stand til å gjette at variabelen heter Jeg i en for loop er et helt tall.
Dårlig programmeringsvaner nr. 6: Jojo-kode
Programmører kaller det "jojo-kode". Først lagres verdiene som strenger. Deretter blir de delt i heltall. Så blir de konvertert tilbake til strenger. Det er veldig ineffektivt. Du kan nesten føle at CPU-en sliter under all ekstra belastning. Smarte programmerere som skriver rask kode, designer arkitekturen for å minimere konverteringene. Koden deres går raskere på grunn av planleggingen.
Men tro det eller ei, noen ganger gir det mening. Noen ganger har du et whiz-bang-bibliotek som gjør en bazillion intelligente ting inne i den proprietære svarte boksen. Noen ganger skrev sjefen en sju-sifret sjekk for å lisensiere alt geni i den sorte boksen. Hvis biblioteket vil ha dataene i strenger, gir du dem til biblioteket i strenger, selv om du nylig har konvertert det til heltall.
Visst, du kan omskrive all koden din for å minimere konverteringen, men det vil ta tid. Noen ganger er det OK at koden går et ekstra minutt, time, dag eller til og med en uke, fordi omskriving av koden vil ta enda mer tid. Noen ganger er det billigere å løpe opp den tekniske gjelden enn å bygge den riktig.
Noen ganger er biblioteket ikke proprietær kode, men kode du skrev selv for lenge siden. Noen ganger er det raskere å konvertere dataene en gang til enn å skrive om alt i biblioteket. Så du følger med og skriver jojo-kode. Det er OK - vi har alle vært der.
Dårlig programmeringsvaner nr. 7: Skriv dine egne datastrukturer
En av standardreglene er at en programmerer aldri skal skrive kode for å lagre data etter å ha fullført datastrukturkurset i løpet av det andre året. Noen andre har allerede skrevet alle datastrukturene vi noen gang trenger, og koden deres har blitt testet og testet på nytt gjennom årene. Det følger med språket, og det er sannsynligvis gratis. Koden din kan bare ha feil.
Men noen ganger er datastrukturbibliotekene litt treg. Noen ganger tvinger de oss til en struktur som kan være standard, men feil for koden vår. Noen ganger presser bibliotekene oss til å konfigurere om dataene våre før vi bruker strukturen. Noen ganger inkluderer bibliotekene belte- og suspenderbeskyttelse med funksjoner som trådlåsing, og koden vår trenger dem ikke.
Når det skjer, er det på tide å skrive våre egne datastrukturer. Noen ganger er det mye, mye raskere. Og noen ganger gjør det koden vår mye renere fordi vi ikke inkluderer all ekstra kode for å formatere dataene nøyaktig slik.
Dårlig programmeringsvaner nr. 8: Gammeldags sløyfer
For lenge siden ønsket noen som opprettet C-språket å kapsle inn alle de abstrakte mulighetene i en enkel konstruksjon. Det var noen ting å gjøre i starten, noen ting å gjøre hver gang gjennom løkken, og en måte å fortelle når det hele var gjort. På den tiden virket det som en helt ren syntaks for å fange uendelige muligheter.
Det var da. Nå ser noen moderne skjeller bare problemer. Det er for mange ting som skjer. Alle disse mulighetene for godhet er også like dyktige. Det gjør lesing og trekking så mye vanskeligere. De elsker det mer funksjonelle paradigmet der det ikke er noen sløyfer, bare funksjoner som brukes på lister, beregningsmaler tilordnet noen data.
Det er tider når den loopløse måten er renere, spesielt når det bare er en pen funksjon og en matrise. Men det er tider når den gammeldagse sløyfen er mye enklere fordi den kan gjøre mye mer. Det er enklere å søke etter den første kampen, for eksempel når du kan stoppe så snart den er funnet.
Videre oppfordrer kartleggingsfunksjoner slurvigere koding når det er flere ting å gjøre med dataene. Tenk deg at du vil ta den absolutte verdien og deretter kvadratroten til hvert tall. Den raskeste løsningen er å kartlegge den første funksjonen og deretter den andre, looping over dataene to ganger.
Dårlig programmeringsvaner nr. 9: Å bryte ut av løkker i midten
Et eller annet sted langs linjen erklærte en regelskapende gruppe at hver sløyfe skulle ha en "invariant", det vil si en logisk uttalelse som er sant i hele sløyfen. Når invarianten ikke lenger er sann, slutter sløyfen. Det er en god måte å tenke på komplekse sløyfer, men det fører til sprø forbud - som å forby oss å bruke en komme tilbake eller a gå i stykker midt i løkken. Dette er en delmengde av regelen som forbyr gå til uttalelser.
Denne teorien er bra, men det fører vanligvis til mer kompleks kode. Tenk på dette enkle tilfellet som skanner en matrise for en oppføring som består en test:
mens jeg<>...
hvis (test (a [i]) så returner en [i];
...
}
Loop-invariante elskere vil heller at vi legger til en annen boolsk variabel, kaller den ikke funnet, og bruk den slik:
mens ((notFound) && (i<>...
hvis (test (a [i])) så notFound = false;
...
}
Hvis denne booleanen er godt kalt, er det et flott stykke selvdokumenterende kode. Det kan gjøre det lettere for alle å forstå. Men det er også lagt til kompleksitet. Og det betyr å tildele en annen lokal variabel og tilstoppe et register som kompilatoren kanskje eller ikke er smart nok til å fikse.
Noen ganger a gå til eller et hopp er renere.
Dårlig programmeringsvaner nr. 10: Omdefinere operatører og funksjoner
Noen av de morsomste språkene lar deg gjøre lure ting som å omdefinere verdien av elementer som ser ut som de skal være konstante. Python, for eksempel, lar deg skrive SANN = FALSK, i det minste i versjon 2.7 og før. Dette skaper ikke en slags logisk kollaps og slutten på universet; det bytter ganske enkelt betydningen av EKTE og FALSK. Du kan også spille farlige spill som dette med C-prosessorer og noen andre språk. Fortsatt andre språk lar deg omdefinere operatører som pluss tegnet.
Dette er en strekning, men det vil være poeng i en stor blokk med kode når det er raskere å omdefinere en eller flere av disse såkalte konstantene. Noen ganger vil sjefen at koden skal gjøre noe helt annet. Visst, du kan jobbe deg gjennom koden og endre enhver forekomst, eller du kan omdefinere virkeligheten. Det kan få deg til å se ut som et geni. I stedet for å skrive om et stort bibliotek, snur du bare litt, og det gjør det motsatte.
Kanskje det er bra å trekke linjen her. Du bør ikke prøve dette hjemme, uansett hvor smart og morsomt det kan være. Dette er for farlig - virkelig ... ærlig.
