Vi har alle gjort det: fanget en cookie, når mor ikke kiggede, havde lidt for meget vin til middag, lad bilen sidde på en parkeringsplads, efter at måleren var udløbet. Vi har endda gået Deadman's Curve lidt for hurtigt rundt. Og ja, vi har alle overtrådt et hvilket som helst antal af hovedreglerne for programmering, dem, som alle er enige om, er dårlige. Og vi kunne i hemmelighed lide det.
Vi har tømt vores næse for reglerne for god programmering, skrevet kode, der er helt dårlig - og vi har levet. Der var ingen lyn fra programmeringsguderne. Vores desktops eksploderede ikke. Faktisk blev vores kode samlet og afsendt, og kunderne syntes tilfredse nok.
Det skyldes, at dårlig programmering ikke er i samme liga som for eksempel at slikke et elektrisk hegn eller trække halen af en tiger. Det meste af tiden fungerer det. Reglerne er oftere retningslinjer eller stilistiske forslag, ikke hurtige direktiver, der skal overholdes, ellers følger kodedøden. Sikker på, din kode kan blive latterliggjort, muligvis endda offentligt. Men det faktum, at du laver konventioner, tilføjer lidt af spændingen ved at undergrave, selv utilsigtet, hvad der svarer til (oftere end ikke) den sociale moral af behagelig kode.
For at gøre sagen mere kompleks er det nogle gange bedre at bryde reglerne. (Shhhh!) Koden kommer renere ud. Det kan endda være hurtigere og enklere. Reglerne er normalt lidt for brede, og en kunstnerisk programmør kan forbedre koden ved at bryde dem. Fortæl ikke din chef, men nogle gange giver det mening at kode din egen måde.
Det følgende er en liste over ni regler, som nogle måske anser for uovervindelige, men mange af os bryder ofte med både succes og glæde.
Dårlig programmeringsvaner nr. 1: Kopiering
Det er forkert at gøre det i skolen. På jobbet er reglerne ikke så klare. Der er bestemt nogle kodeblokke, der ikke bør stjæles. Hvis det kommer fra proprietær kode, skal du ikke folde den i din stak, især hvis den er markeret med en copyrightbesked. Skriv din egen version. Det er hvad de betaler dig for at gøre.
Det vanskeligere spørgsmål kommer, når den oprindelige skaber vil dele. Måske er det i en af disse online programmeringsfora. Måske er det open source-kode med en licens (BSD, MIT), der tillader at fange en funktion eller tre. Der er ingen juridisk grund til at stoppe dig. Og du får betalt for at løse problemer, ikke genopfinde hjulet.
For det meste er fordelene ved kopiering overbevisende, og ulemperne kan begrænses med lidt omhu. Koden, du får fra en velrenommeret kilde, har allerede haft mindst en tankeomgang anvendt på den. Den oprindelige forfatter søgte efter en løsning og fandt noget. Loop-invarianterne og datastrømmen er udarbejdet.
De vanskelige spørgsmål er, om der er nogle ubegrundede fejl eller nogle forskellige antagelser om rollen eller de underliggende data. Måske blandes din kode i nulmarkører, mens den oprindelige kode aldrig kontrollerede dem. Hvis du kan løse problemerne, er det som om din chef får input fra to programmører. Det er parprogrammering uden de smarte skriveborde.
Dårlig programmeringsvaner nr. 2: Ikke-funktionel kode
I det sidste årti eller deromkring har det funktionelle paradigme været stigende. Akolytterne til opbygning af dit program ud af indlejret funktion kalder kærlighed til at citere undersøgelser, der viser, hvordan koden er sikrere og mere bug-fri end den ældre stil af variabler og sløjfer, alt sammen spændt sammen på en hvilken som helst måde gør programmøren glad. De hengivne taler med ægte troendes nidkær og tugter ikke-funktionelle tilgange i kodevurderinger og trækforespørgsler. De kan endda have ret i fordelene.
Men nogle gange er du bare nødt til at få en rulle af tape. Vidunderligt konstrueret og yndefuldt planlagt kode tager tid, ikke kun at forestille sig, men også at konstruere og senere at navigere. Alle disse lag tilføjer kompleksitet, og kompleksitet er dyrt. Udviklere af smuk funktionel kode har brug for at planlægge og sikre, at alle data videregives ad de rette veje. Nogle gange er det bare nemmere at nå ud og ændre en variabel. Måske lægge en kommentar for at forklare det. Selv at tilføje en lang, skræmmende undskyldning til fremtidige generationer i kommentaren er hurtigere end at omarkitekturere hele systemet for at gøre det på den rigtige måde.
Dårlig programmeringsvaner nr. 3: Ikke-standardafstand
De fleste rum i software har ingen indflydelse på, hvordan programmet fungerer. Bortset fra et par sprog som Python, der bruger afstanden til at angive kodeblokke, har de fleste mellemrum nul effekt på, hvordan programmet opfører sig. Der er stadig obsessive programmører, der tæller dem og insisterer på, at de betyder noget. En af dem fortalte engang min chef i den mest seriøse tone, at jeg skrev "Ikke standardkode", og han kunne se det med det samme. Min synd? Overtrædelse af ESLint-rummet-infix-ops-reglen ved ikke at sætte et mellemrum på begge sider af et ligetegn.
Nogle gange skal man bare tænke på noget dybere end placeringen af mellemrum. Måske bekymrer du dig om, at databasen bliver overbelastet. Måske bekymrer du dig på en eller anden måde for, at en nulmarkør kan gå ned i din kode. Stort set enhver del af koden er vigtigere end mellemrummene, selvom neb-nosed, bossy standardudvalg har fyldt sider med regler om placeringen af disse mellemrum eller faner.
Den fantastiske ting er, at der er flere gode værktøjer, der automatisk omformaterer din kode for at overholde eventuelle veldefinerede lineregler. Mennesker behøver ikke bruge tid på at tænke over dette. Hvis det er så vigtigt, kan de køre det gennem værktøjet for at rydde op i problemet.
Dårlig programmeringsvaner nr. 4: Brug gå til
Forbudet mod at bruge gå til stammer fra æraen, før mange af værktøjerne til struktureret programmering endda eksisterede. Hvis programmører ville oprette en loop eller springe til en anden rutine, ville de være nødt til at skrive GÅ TIL efterfulgt af et linjenummer. Efter et par år lader kompilatorhold programmører bruge en strengetiket i stedet for et linjenummer. Det blev betragtet som en hot ny funktion dengang.
Nogle kaldte resultatet "spaghetti-kode." Det var umuligt for nogen at læse din kode senere og følge stien til udførelse. Det var et virvar af tråde, for altid sammenfiltret. Edsger Dijkstra forbød kommandoen med et manuskript med titlen "Gå til erklæring betragtet som skadelig."
Men absolut forgrening er ikke problemet. Det er det virvar, der resulterer. Ofte en kunstnerisk pause eller Vend tilbage vil tilbyde en meget ren erklæring om, hvad koden laver på det sted. Nogle gange tilføjer gå til til en sagserklæring vil producere noget, der er enklere at forstå end en mere korrekt struktureret liste over cascading if-then-else-blokke.
Der er modeksempler. Sikkerhedshullet "goto fail" i Apples SSL-stack er et af de bedste tilfælde. Men hvis vi er omhyggelige med at undgå nogle af de knasende problemer med sagserklæringer og sløjfer, kan vi indsætte gode, absolutte spring, der gør det lettere for læseren at forstå, hvad der foregår. Vi kan sætte et pause eller a Vend tilbage det er renere og mere behageligt for alle - undtagen måske gå til hadere.
Dårlig programmeringsvaner nr. 5: Ikke deklarere typer
De mennesker, der elsker typede sprog, har et punkt. Vi skriver bedre og mere fejlfri kode, når vi tilføjer klare erklæringer om datatypen for hver variabel. Hvis du stopper et øjeblik for at stave typen, hjælper compileren med at markere dumme fejl, før koden begynder at køre. Det kan være en smerte, men det hjælper. Det er en bælte-og-seler-tilgang til programmering, der stopper bugs.
Tiderne har ændret sig. Mange af de nyere kompilatorer er kloge nok til at udlede typen ved at se på koden. De kan arbejde frem og tilbage gennem koden, indtil de kan være sikre på, at variablen skal være a snor eller en int eller noget andet. Og hvis disse afledte typer ikke stemmer overens, kan kompilatorerne hæve et fejlflag. De har ikke brug for os til at skrive variablerne mere.
Dette betyder, at det nu er nemmere at gemme et par bits ved at lade nogle af de enkleste erklæringer ud. Koden bliver lidt renere, og læseren er normalt ret i stand til at gætte, at den navngivne variabel jeg i en for loop er et heltal.
Dårlig programmeringsvaner nr. 6: Yo-yo-kode
Programmører kalder det "yo-yo-kode". Først gemmes værdierne som strenge. Derefter analyseres de i heltal. Derefter konverteres de tilbage til strenge. Det er frygteligt ineffektivt. Du kan næsten mærke, at CPU'en kæmper under al den ekstra belastning. Smarte programmører, der skriver hurtig kode, designer deres arkitekturer for at minimere konverteringerne. Deres kode kører hurtigere på grund af deres planlægning.
Men tro det eller ej, nogle gange giver det mening. Nogle gange har du et whiz-bang-bibliotek, der gør en bazillion intelligente ting inde i sin proprietære sorte boks. Undertiden skrev chefen en syv-cifret check for at licensere alt geni inde i den sorte boks. Hvis biblioteket vil have dataene i strenge, giver du dem til biblioteket i strenge, selvom du for nylig har konverteret det til heltal.
Sikker på, du kunne omskrive al din kode for at minimere konverteringen, men det ville tage tid. Nogle gange er det OK, at koden kører et ekstra minut, en time, en dag eller endda en uge, fordi omskrivning af koden vil tage endnu mere tid. Undertiden er det billigere at løbe den tekniske gæld end at bygge det rigtigt i første omgang.
Nogle gange er biblioteket ikke proprietær kode, men kode, du skrev selv for længe siden. Nogle gange er det hurtigere at konvertere dataene en gang mere end at omskrive alt i biblioteket. Så du går sammen, og du skriver jojo-kode. Det er OK - vi har alle været der.
Dårlig programmeringsvaner nr. 7: Skriv dine egne datastrukturer
En af standardreglerne er, at en programmør aldrig skal skrive kode til lagring af data, når de har gennemført datastrukturkurset i deres andet år. En anden har allerede skrevet alle de datastrukturer, vi nogensinde har brug for, og deres kode er blevet testet og testet igen gennem årene. Det følger med sproget, og det er sandsynligvis gratis. Din kode kunne kun have fejl.
Men nogle gange er datastrukturbibliotekerne lidt langsomme. Nogle gange tvinger de os ind i en struktur, der kan være standard, men forkert for vores kode. Undertiden skubber bibliotekerne os til at omkonfigurere vores data, inden vi bruger strukturen. Undertiden inkluderer bibliotekerne beskyttelse af bælter og bælter med funktioner som trådlåsning, og vores kode har ikke brug for dem.
Når det sker, er det tid til at skrive vores egne datastrukturer. Nogle gange er det meget, meget hurtigere. Og nogle gange gør det vores kode meget renere, fordi vi ikke inkluderer al den ekstra kode til omformatering af dataene nøjagtigt.
Dårlig programmeringsvaner nr. 8: Gammeldags sløjfer
For længe siden ønskede nogen, der skabte C-sproget, at indkapsle alle de abstrakte muligheder i en simpel konstruktion. Der var nogle ting, der skulle gøres i starten, nogle ting at gøre hver gang gennem løkken og en eller anden måde at fortælle, hvornår det hele var gjort. På det tidspunkt virkede det som en perfekt ren syntaks til at fange uendelige muligheder.
Det var dengang. Nu ser nogle moderne skæld kun problemer. Der foregår for mange ting. Alle disse muligheder for godhed er også i stand til ondskab. Det gør læsning og grokking så meget sværere. De elsker det mere funktionelle paradigme, hvor der ikke er nogen sløjfer, kun funktioner, der anvendes på lister, beregningsskabeloner tilknyttet nogle data.
Der er tidspunkter, hvor den sløjfeløse måde er renere, især når der kun er en pæn funktion og en matrix. Men der er tidspunkter, hvor den gammeldags loop er meget enklere, fordi den kan gøre meget mere. At søge efter den første kamp er for eksempel enklere, når du kan stoppe, så snart den er fundet.
Desuden tilskynder kortlægningsfunktioner mere sløvere kodning, når der er flere ting, der skal gøres med dataene. Forestil dig, at du vil tage den absolutte værdi og derefter kvadratroden af hvert nummer. Den hurtigste løsning er at kortlægge den første funktion og derefter den anden, looping over dataene to gange.
Dårlig programmeringsvaner nr. 9: At bryde ud af sløjfer i midten
Et eller andet sted langs linjen erklærede en gruppe, der fremstiller regler, at hver løkke skal have en "invariant", det vil sige en logisk erklæring, der er sand gennem hele løkken. Når invarianten ikke længere er sand, slutter sløjfen. Det er en god måde at tænke på komplekse sløjfer, men det fører til skøre forbud - som at forbyde os at bruge en Vend tilbage eller a pause midt i sløjfen. Dette er en delmængde af reglen om forbud gå til udsagn.
Denne teori er fint, men det fører normalt til en mere kompleks kode. Overvej denne enkle sag, der scanner en matrix for en post, der består en test:
mens jeg<>...
hvis (test (a [i]) derefter returnere en [i];
...
}
De loop-invariante elskere vil hellere tilføje en anden boolsk variabel, kalde den ikke fundet, og brug det således:
mens ((notFound) && (i<>...
hvis (test (a [i])) så notFound = false;
...
}
Hvis denne booleske er godt navngivet, er det et godt stykke selvdokumenterende kode. Det kan gøre det lettere for alle at forstå. Men det er også tilføjet kompleksitet. Og det betyder at tildele en anden lokal variabel og tilstoppe et register, som compileren måske eller måske ikke er smart nok til at rette.
Nogle gange a gå til eller et spring er renere.
Dårlig programmeringsvaner nr. 10: Omdefinerer operatører og funktioner
Nogle af de mest sjove sprog giver dig mulighed for at gøre ægte ting som omdefinere værdien af elementer, der ser ud til at være konstant. Python, for eksempel, lader dig skrive SAND = FALSK, i det mindste i version 2.7 og før. Dette skaber ikke en slags logisk sammenbrud og universets ende; det bytter simpelthen betydningen af RIGTIGT og FALSK. Du kan også spille farlige spil som dette med C-forprocessorer og nogle andre sprog. Stadig andre sprog giver dig mulighed for at omdefinere operatører som plustegnet.
Dette er en strækning, men der vil være punkter i en stor blok kode, når det er hurtigere at omdefinere en eller flere af disse såkaldte konstanter. Undertiden ønsker chefen, at koden skal gøre noget helt andet. Sikker på, du kan arbejde igennem koden og ændre enhver begivenhed, eller du kan omdefinere virkeligheden. Det kan få dig til at ligne et geni. I stedet for at omskrive et stort bibliotek, vender du simpelthen lidt, og det gør det modsatte.
Måske er det godt at trække grænsen her. Du bør ikke prøve dette derhjemme, uanset hvor smart og sjovt det kan være. Dette er for farligt - virkelig ... ærligt.
