Kodeanmeldelser: Almindelige kilder til ekstreme krænkelser og hvordan man undgår argumenter om rettelse af dem

Knive tegnes. Bladene er skærpet for konflikt. En tvist raser mellem udviklere. Koders lidenskaber betændes ikke over buggy-software, men over uredeligt kortfattet eller ordret kode. Disse linjer er tegn på et hack. Enhver programmør, der er uenig, er en amatør. Kun en neophyte ville producere metoder og blokke, der så klart er i strid med god smag. Alligevel er forskellige præferencer, ikke naturlove, kilden til denne konflikt og vitriolen. Hat mellem udviklere er i dette tilfælde resultatet af forskellige tilbøjeligheder til handel med kortfattethed i forskellige mål. Disse mål, og tendensen til dem, er forskellige for enhver udvikler, hvilket fører til konstant konflikt på visse områder. Et sådant sted er en ordlig kode eller en lille kode. For at minimere kamp kan et hold bruge kodevurderinger til at fremhæve de mest ubehagelige segmenter, og gruppen kan diskutere over disse dele i stedet for at krangle over hver linje og blok i en kodebase.

Visse kodekonstruktioner eller teknikker producerer sandsynligvis de ekstreme krænkelser og fører argumenter for at korrigere disse overtrædelser. At afhjælpe disse misbrug fører til intense argumenter. Disse uoverensstemmelser kan løses eller i det mindste afskaleres for de særlige sproglige træk og teknikker, der er anført nedenfor.

Betinget operatør vs. if-erklæring

De sproglige elementer, betinget operatør og if-statement, fører til argumenter, med forskellige lejre, der argumenterer for, at hver enkelt er den overlegne teknik til visse operationer. Disse handlinger kan implementeres på utallige måder, idet hver teknik bringer fordele og ulemper.

Hvis udsagn: If-udsagnet kan bidrage til grusomt voluminøs kode, når tætheden af ​​betingelserne er høj. En høj tæthed får en blok eller metode til at virke puffet. Alligevel er kode, der er skrevet med if-udsagn, også meget debugterbar, da en udvikler kan gå gennem hver linje.

hvis (label1IsRequired) {
 label1.Color = “rød”;
} andet {
 label1.Color = “sort”;
}
hvis (label2IsRequired) {
 label2.Color = “rød”;
} andet {
 label2.Color = “sort”;
}
hvis (label3IsRequired) {
 label3.Color = “rød”;
} andet {
 label3.Color = “sort”;
}

Betinget operatør: Den betingede operatør kan føre til nogle åbenlyst stramme linjer, når den bruges som erstatning for flere if-udsagn. Indbyggede betingede operatører laver kode, når de tages til det ekstreme, meget vanskeligt at læse, teste eller fejlsøge. Enhver blok eller metode, der er tung på betingede operatører, er også meget kompakt, hvilket reducerer mængden af ​​kode, som en udvikler skal scanne.

healthIndicatorColor = (sundhed == “God”)? “Grøn”: (sundhed == “Fair”)? “Gul”: (sundhed == “dårlig”)? "Rød": (sundhed == "life_support")? “Orange”: “lilla”;

Potentiel opløsning: Betingede operatører er en fordel, når de erstatter en høj tæthed af værdier, der er baseret på betingelser implementeret gennem if-udsagn. Betingede operatører er destruktive, når de erstatter selv et par beslutninger indlejret i hinanden. Imperativer, der kan læses let på en linje, er et hovedmål for betingede operatører, mens forhold, der kræver flere linjer, er domænet for if-udsagn. Enhver uregelmæssig brug af if-erklæringer eller betingede operatører bør korrigeres for at implementere den passende anvendelse af en af ​​disse konstruktioner. (Bemærk: Ændring kan muligvis kræve betydelig refactoring.)

if (sundhed == “God”) {
 healthIndicatorColor = “grøn”;
} andet hvis (sundhed == “Fair”) {
 healthIndicatorColor = “gul”;
} andet hvis (sundhed == “dårlig”) {
 healthIndicatorColor = “rød”;
} andet hvis (sundhed == “life_support”) {
 healthIndicatorColor = “orange”;
} andet {
 healthIndicatorColor = “lilla”;
}
label1.Color = (label1IsRequired)? "Rød": "sort";
label2.Color = (label2IsRequired)? "Rød": "sort";
label3.Color = (label3IsRequired)? "Rød": "sort";

Multiple Return Statements vs. One Return Statement

To særlige stilarter, der fører til argumenter, er flere returer og enkelt returnerer. Der er uenighed om, hvorvidt metoder skal have en returserklæring, eller om flere retursangivelser er acceptabelt. Hver tilgang har positive og negative.

Udsagn om flere afkast: Udsagn om flere afkast kan bidrage til kode, der er vanskeligt at forstå, følge og teste. Metoder med flere returer kan dog være kortere end funktioner med et enkelt retur.

SomeDataType someMethod (param1, param2, param3) {
 SomeDataType retVal;
 if (param1 == null) {
 retVal = null
 }
 if (retVal == null) {
 returretur;
 }
 
 if (param2! = null) {
 retVal = param2;
 }
 hvis (retVal.Equals (param2)) {
 returretur;
 }
 
 retVal = param3;
 returretur;
}

Én afleveringserklæring: En enkelt returretning kan føre til lange metoder. Alligevel har disse procedurer en enkelt punktudgang, hvilket forenkler test og fejlfinding.

SomeDataType someMethod () {
 SomeDataType retVal;
 // hundreder eller tusinder af linjekoder
 returretur;
}

Potentiel opløsning: Flere returneringer gør koden svær at forstå, følge og teste, når de bruges inkonsekvent. Enkelte udsagnsangivelser fører til lange metoder, når de videreføres af lange kodestykker. Disse udtrukkede spenn kan forkortes eller i det mindste gøres læsbare ved at bruge flere return-udsagn i stedet for en. Enkelt returnering er helt acceptabelt, når de følger korte kodekoder. Enhver blændende misbrug af en enkelt return-statement eller flere returneringer skal rettes til at anvende en accepteret brugssag for en af ​​disse stilarter. (Bemærk: Korrektion kan kræve betydelig refactoring.)

SomeDataType someMethod (param1, param2, param3) {
 if (param1 == null || param3 == null) {
 returnere null;
 }
 
 SomeDataType retVal = null;
 if (param2! = null {
 retVal = param2;
 } andet hvis (param1! = null) {
 retVal = param1;
 } ele if (param3! = null) {
 retVal = param3;
 }
 returretur;
}
SomeDataType someMethod (param1, param2) {
 SomeDataType retVal = null;
 for (int i = 0; i  hvis (param1 [i] .equals (param2)) {
 retVal = param1 [i];
 pause;
 }
 }
 returretur;
} Brud og fortsæt brug i sløjfer

Pause- og fortsættelseskonstruktionerne er genstand for intense debatter. På den ene side af argumentet hævder udviklere, at brud og fortsættelse kan forenkle kontrolstrømmen. Andre programmerere hævder, at disse funktioner komplicerer et programs logik. Break and continue kan bestemt bruges til at forenkle eller komplicere kode. Disse linjer kan opdages.

Brug og fortsæt brug: Elementerne kan forenkle kode, men de kan også unødvendigt komplicere dem.

SomeDataType someMethod (param1, param2) {
 SomeDataType retVal = null;
 for (int i = 0; i  if (param1 [i] == null) {
 Blive ved;
 }
 hvis (param1 [i] .equals (param2)) {
 retVal = param1 [i];
 pause;
 }
 }
 returretur;
}
SomeDataType someMethod (data, param1) {
 SomeDataType retVal = null;
 gør noget:
 for (int i = 0; i  hvis (i> = data.length) {
 pause;
 }
 hvis (data [i] .equals (param1)) {
 retVal = data [i];
 } andet {
 Blive ved;
 }
 }
if (retVal == null) {
 data - refreshData ();
 gå til dosering;
 }
returretur;
}

Potentiel opløsning: De fleste udviklere hævder, at kode skal bruge enkle mekanismer til kontrolstrøm. Hvilke specifikke mekanismer, der er enkle, er kilden til debatten. Dette argument bliver meget mindre opvarmet, når hvert instrument bruges på vidt accepterede måder. Accepterede tilgange findes til pause og fortsætter. Hold dig til disse konventioner for at forhindre uoverensstemmelser og for at forenkle kontrolstrømmen. Ethvert middel til kontrol, der alvorligt overtræder disse standarder, bør korrigeres uden debat.

SomeDataType someMethod (data, param1) {
 SomeDataType retVal = null;
 for (int i = 0; i  if (data [i] == null) {
 Blive ved; // spring resten af ​​loopen over
 }
 hvis (data [i] .equals (param2)) {
 retVal = data [i];
 pause; // ikke sløjfe mere b / c jeg er færdig
 }
 }
 returretur;
}

Defensive undtagelser

Undtagelser er et middel til at indikere et problem eller afværge et fremtidig problem. Hvilke hovedpine skal angives eller afværges af hvilke dele af koden, der er genstand for hård debat. I den ene ende af uenigheden hævder kodere, at gennemgribende defensive undtagelser forhindrer fejl og gør dem lette at placere. Denne vasketøjsliste med forsvar kan dog gøre kodning oppustet og vanskelig at forstå, som nogle programmerere har hævdet. Udviklere på begge sider af debatten har et punkt. Defensive undtagelser har både fordele og ulemper.

Fordele og ulemper ved defensive undtagelser: Beskyttelse mod fejl og andre problemer kan beskyttes mod minimale ulemper ved hjælp af defensive undtagelser. Disse mangler bliver forstørret, når teknikken er ubetinget.

ugyldigt someMethod (param1, param2) {
 if (param1 == null || param2 == null) {
 kaste ny ArgumentNullException (“En eller flere parametre mangler”);
 }
 // gør metoden ting
}
ugyldigt someMethod (param1, param2) {
 // snesevis af linjer med defensiv kontrol… ..
 // Gør resten af ​​metoden
}

Potentialeløsning: Manglerne ved defensive undtagelser er de mindste, når de anvendes i accepterede anvendelser. Enhver anvendelse af teknikken, der strammer fra disse konventioner, bør korrigeres, medmindre der er angivet en overbevisende grund.

public void someMethod (param1, param2) {
 // Kontroller hver parameter i en offentlig metode
 if (param1 == null || param2 == null) {
 kaste ny ArgumentNullException (“En eller flere parametre mangler”);
 }
 
 // afværge problemer forårsaget af ugyldige data
 hvis (! isValid (param1) ||! isValid (param2)) {
 kaste ny InvalidParameterException ("En eller flere parametre er ugyldig");
 }
 
 // gør noget med parametre
}

Wrap-up

Disse kodekonstruktioner og teknikker bruges af både gode og dårlige udviklere. Programmerere er mennesker. Mennesker har tendenser. Disse tilbøjeligheder manifesterer sig i kode. Lejlighedsvis fører impulser fra en udvikler ham til at skrive kode, som andre kodere med rette kritiserer. Udvikleren, der bliver ledsaget af, er ikke nødvendigvis en dårlig programmør. Koderen, der kritiserer ham, er ikke nødvendigvis en god udvikler. Begge mennesker er sandsynligvis blevet ført på afveje på et tidspunkt af deres præferencer. Disse ønsker bør ikke føre til, at udviklingen udgår til en uendelig strøm af fornærmelser, der kaster sig mod hinanden. Snarere bør programmerere gennemgå hinandens kode, begrænse deres kampe til dets værste sektioner og blive enige om at afvikle visse argumenter gennem ovenstående regler.