Programmering stil

Programmering stil er et sæt regler eller retningslinjer, der anvendes, når du skriver kildekoden til et computerprogram. Det hævdes ofte, at der efter en bestemt programmering stil vil hjælpe programmører til at læse og forstå kildekoden er i overensstemmelse med den stil, og bidrage til at undgå at indføre fejl.

En klassisk værk om emnet var elementerne i programmering stil, skrevet i 1970'erne, og illustreret med eksempler fra Fortran og PL / I Sprog udbredt fænomen på det tidspunkt.

Programmeringen stil brugt i et bestemt program, kan være afledt af de kodende konventioner et selskab eller anden computing organisation, samt præferencer forfatteren af ​​koden. Programmering stilarter er ofte udviklet til en bestemt programmeringssprog: stil anses for god i C kildekode kan ikke være passende for BASIC kildekode, og så videre. Der er dog nogle regler almindeligvis anvendes på mange sprog.

Elementer af god stil

God stil er en subjektiv sag, og er vanskelig at definere. Der er imidlertid flere elementer er fælles for et stort antal programmering stilarter. De spørgsmål normalt betragtes som en del af programmering stil omfatter layoutet af kildekoden, herunder indrykning; brugen af ​​hvide rum omkring operatører og søgeord; kapitalisering eller på anden måde af søgeord og variable navne; stil og stavning af brugerdefinerede identifikatorer, såsom funktion, procedure og variabelnavne; og brug og stil af kommentarer.

Kode udseende

Programmering stilarter almindeligvis beskæftiger sig med det visuelle udseende af kildekode, med det mål at kræver mindre menneskelig kognitiv indsats for at udtrække information om programmet. Software har længe været til rådighed, der formaterer kildekode automatisk, så programmører til at koncentrere sig om navngivning, logik, og højere teknikker. Som en praktisk, at anvende en computer til at formatere kildekode sparer tid, og det er muligt at håndhæve derefter hele virksomheden standarder uden debat.

Indrykning

Led stilarter hjælpe med at identificere kontrol flow og blokke af kode. I nogle programmeringssprog indrykning bruges til at afgrænse logiske blokke af kode; korrekt indrykning i disse tilfælde er mere end et spørgsmål om stil. I andre sprog indrykning og hvid plads påvirker ikke funktionen, selv om logisk og konsekvent indrykning gør kode mere læsbar. Sammenligne:

eller

med noget som

De to første eksempler er sandsynligvis meget lettere at læse, fordi de er indrykket i et etableret måde. Denne indrykning stil er især nyttig, når der beskæftiger sig med flere indlejrede konstruktioner.

ModuLiq

De ModuLiq Zero indrykning Style grupper med linjeskift i stedet led. Sammenlign alle ovenstående til:

Lua

Lua ikke bruge den traditionelle krøllede parenteser eller parentes. hvis / else udsagn kræver kun dit udtryk blive efterfulgt af, og lukke din hvis / ellers redegørelse med.

Indrykning er valgfrit.

Python

Python bruger indrykning for at angive kontrolstrukturer, så korrekt indrykning er påkrævet. Ved at gøre dette, er behovet for bracketing med krøllede parenteser elimineret. På den anden side kopiere og indsætte Python kode kan føre til problemer, fordi fordybningen af ​​den indsatte koden ikke kan være den samme som indrykningen af ​​den aktuelle linje. En sådan omformatering kan være trættende at gøre i hånden, men nogle teksteditorer og IDE'er har funktioner til at gøre det automatisk. Der er også problemer, når Python kode, der ydede ubrugelig når de offentliggøres på et forum eller en webside, der fjerner hvide rum, selv om dette problem kan undgås, hvor det er muligt at vedlægge koden i hvide rum-bevare tags som "& lt; pre & gt ;. .. & lt; / pre & gt; "," "..." "osv

Bemærk, at Python ikke bruger krøllede parenteser, men en regelmæssig kolon.

Haskell

Haskell ligeledes har off-side reglen som lader indrykning definerer blokke. Men i modsætning til Python, anvender Haskell mellemrum på denne måde blot som en form for syntaktisk sukker eksplicitte krøllede parenteser og semikolon kan bruges i stedet.

Vertikal justering

Det er ofte nyttigt at tilpasse lignende elementer lodret, for at gøre typo-genereret bugs mere indlysende. Sammenligne:

med:

Sidstnævnte eksempel gør to ting intuitivt klare, som ikke var klar i den tidligere:

  • søgningen og erstatte udtryk er relateret og matche op: de er ikke diskrete variable;
  • der er endnu søgeord, end der er udskiftning vilkår. Hvis dette er en fejl, er det nu mere tilbøjelige til at blive spottet.

Bemærk dog, at der er mange argumenter imod lodrette justering:

  • Inter-line falske afhængigheder; tabelform formatering skaber afhængigheder på tværs af linjer. For eksempel, hvis der tilsættes en identifikator med en lang navn til en tabellayout, kan kolonnebredden skal øges for at imødekomme den. Dette tvinger en større ændring af kildekoden end nødvendigt, og væsentlige ændring kan gå tabt i støjen. Dette er til skade for Revision kontrol, hvor inspektion forskelle mellem versionerne er afgørende.
  • Skørhed; hvis en programmør ikke pænt formatere tabellen, når du foretager en ændring, måske lovligt med det foregående punkt i tankerne, resultatet bliver et rod, forringes med yderligere sådanne ændringer. Simple refactoring operationer, såsom søg-og-erstat, kan også bryde formateringen.
  • Modstand mod forandring; tabelform formatering kræver en større indsats at vedligeholde. Dette kan udskyde en programmør fra at gøre en gavnlig forandring, såsom at tilføje, ændre eller forbedre navnet på en identifikator, fordi det vil ødelægge formateringen.
  • Afhængigheden af ​​mono-afstand font; tabelform formatering forudsætter, at redaktøren bruger en skrifttype med fast bredde. Mange moderne kode redaktører understøtter proportionale skrifttyper, og programmøren kan foretrække at bruge en proportional skrifttype for læsbarheden.
  • Værktøj afhængighed; nogle af bestræbelserne på at opretholde alignment kan afhjælpes ved værktøjer, selv om der skaber en afhængighed af sådanne værktøjer.

For eksempel, hvis en simpel refactoring operation udføres på ovenstående kode, omdøbning variabler "$ erstatning" til "$ r" og "$ anothervalue" til "$ a", vil den resulterende kode se således ud:

Den oprindelige sekventielle formatering vil stadig se fint efter en sådan ændring:

Mellemrum

I de situationer, hvor nogle hvide rum er påkrævet grammatikker de fleste gratis-format sprog er ligeglade med det beløb, der vises. Style relateret til hvide rum er almindeligt anvendt til at forbedre læsbarheden. Der er i øjeblikket ingen kendte hårde fakta om, hvilke af de blanke stilarter har den bedste læsbarhed.

For eksempel Sammenlign Følgende syntaktisk tilsvarende eksempler på C-kode:

imod

imod

imod

Faner

Brugen af ​​faner til at skabe hvide rum præsenterer særlige spørgsmål, når ikke nok omhu, fordi placeringen af ​​tabelopstilling tidspunkt kan være forskellige afhængigt af de værktøjer, der bruges, og selv de præferencer for brugeren.

Som et eksempel, en programmør foretrækker tabulatorstop på fire og har hans værktøjssæt konfigureret på denne måde, og bruger disse til at formatere sin kode.

En anden programmør foretrækker tabulatorstop på otte, og hans værktøjssæt er konfigureret på denne måde. Da han undersøger sin kode, kan han godt finde det vanskeligt at læse.

Et bredt anvendt løsning på dette problem kan indebære forbyder brug af faner til tilpasning eller regler om, hvordan tabulatorstop skal indstilles. Bemærk, at fanerne arbejde fint forudsat at de anvendes konsekvent, begrænset til logisk indrykning, og anvendes ikke til tilpasning:

  0   0
Forrige artikel Bahrain Skole
Næste artikel A. J. M. Smith

Kommentarer - 0

Ingen kommentar

Tilføj en kommentar

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tegn tilbage: 3000
captcha