Fordele og ulemper (men hovedsageligt fordele) ved kommentarer i kode

Billede: scyther5, Getty Images / iStockphoto

Skal du tilføje kommentarer til din kode eller ej? Svaret er selvfølgelig ja. Det er også nej. Eller, mindre facetisk, "Du skal først stræbe efter at gøre din kode så enkel som muligt at forstå uden at stole på kommentarer som en krykke. Kun på det punkt, hvor koden ikke kan gøres lettere at forstå, skal du begynde at tilføje kommentarer." Jeff Atwood lavede det tilbage i 2006, men det er lige så relevant i dag, som det var dengang. Måske mere.

Sådan bygger du en succesrig udviklerkarriere (gratis PDF)

Sagen mod kommentarer

Gør emnet op, og uundgåeligt (og snart) vil nogen fortælle dig, hvorfor du ikke bør rod din kode med kommentarer. En af de primære klager over kommentarer er, at de tilføjer støj til kodens signal. "God kode er selvdokumenterende, " siger ordsproget, og tilføjelse af kommentarer kan undertiden tjene til at maske dårlig kode og ikke til det bedre. Som Bennett Garner har skrevet:

Dette er dårligt nok, men problemet opstår efterhånden som kommentarer bliver ældre. Som Marco Bresciani har hævdet: "Tro ikke på kommentarer: de er aldrig opdateret. Kun koden fortæller sandheden." Kommentarer kan have været nyttige på et tidspunkt, men som kodeændringer (og det er almindeligt), gør kommentarerne ofte ikke. Dette efterlader koden rodet med forældede kommentarer, der kan ende med at forvirre snarere end at afklare. "Ideelt set ville udviklere opdatere deres kommentarer, når de opdaterer koden, men det har en tendens til ikke at ske.

Selvfølgelig understøtter de fleste kodeditorer kodefoldning, som skjuler kommentarer og giver udviklere mulighed for bare at se på kildekoden. Men dette antager, at kommentarer altid er dårlige, hvilket ikke er sandt. Hvornår kan de være berettiget?

Sagen til kommentarer

Prøv så meget som du måske for at få din kode til "selvdokumenterende", en ting, som en ting ikke kan gøre: Forklar hvorfor bag koden. Som Jef Raskin har bemærket, "T den grundlæggende årsagskode kan aldrig være selvdokumenterende, og automatiske dokumentationsgeneratorer kan ikke oprette, hvad der er nødvendigt, er at de ikke kan forklare, hvorfor programmet skrives, og grunden til at vælge denne eller den anden metode. De kan ikke diskutere årsagerne til, at der blev taget alternative løsninger. " Du kan f.eks. Være nødt til at forklare, hvorfor en ikke-intuitiv sti blev taget, som Bill Sourour kalder, og derved redde fremtidige udviklere besværet med den mere indlysende (men forkerte) tilgang.

Igen bør den primære vægt være at skrive en høj kvalitet, kortfattet kode, der (mere eller mindre) forklarer sig selv. Hvor dette ikke er muligt (og det er ikke altid muligt), "Tænk på kommentarer som prikken over i'et, der findes for at give læseren oplysninger, der ikke let kan udtrykkes med selve koden, " til at bruge Brian Hannaways ord.

Det er vigtigt, fortsætter han, at det er kritisk at holde dit publikum i tankerne. Det er en dårlig antagelse at tro, at de, der kommer efter din kode senere, vil have det samme niveau af ekspertise. Som sådan har han foreslået at imødekomme de mindre erfarne:

I summen er der store grunde til at holde kommentarer til et minimum, men de undgår ikke behovet for kommentarer helt. Du har brug for efterfølgende udviklere for at kunne forstå din kode: Det starter med at skrive ren, kortfattet kode, men slutter med lige nok kommentarer til at hjælpe dem med at forstå, hvorfor du gjorde tingene på en bestemt måde.

Open Source Ugentlig nyhedsbrev

Du vil ikke gå glip af vores tip, tutorials og kommentarer til Linux OS og open source-applikationer. Leveres tirsdage

Tilmeld dig i dag

© Copyright 2020 | mobilegn.com