Koodi ülevaated: äärmuslike rikkumiste levinumad allikad ja kuidas vältida argumente nende parandamise kohta

Noad on joonistatud. Terad on teravdatud konflikti jaoks. Arendajate vahel on vaidlus. Kodeerijate kired ei ole põrmustatud mitte lollaka tarkvara tõttu, vaid ülimalt lühikese või paljusõnalise koodi tõttu. Need read on märgid häkkimisest. Iga programmeerija, kes ei nõustu, on amatöör. Ainult neofüüt tooks välja meetodeid ja plokke, mis nii selgelt rikuvad head maitset. Selle konflikti ja vitriooli põhjuseks on erinevad eelistused, mitte loodusseadused. Vaen arendajate vahel on sel juhul erinev kalduvus eri otstarbel lühidalt kaubelda. Need eesmärgid ja kalduvus nende poole on igal arendajal erinevad, põhjustades teatud piirkondades pidevat konflikti. Üks selline koht on sõna- või armeeritud kood. Võitluse minimeerimiseks võib meeskond kasutada koodivaateid, et tõsta esile kõige koledamaid segmente ja rühm võib vaidleda nende osade üle, selle asemel, et vaidleda koodialuse iga rea ​​ja ploki üle.

Teatud koodikonstruktsioonid või -tehnikad põhjustavad tõenäoliselt äärmuslikke rikkumisi ja pakuvad argumente nende rikkumiste parandamiseks. Nende kuritarvituste parandamine põhjustab intensiivseid argumente. Need lahkarvamused saab lahendada või vähemalt kahandada allpool loetletud konkreetsete keeleliste tunnuste ja tehnikate osas.

Tingimuslik operaator vs. avaldus

Keelelised elemendid, tingimuslik operaator ja if-lause, viivad argumentideni, kusjuures erinevad leerid väidavad, et igaüks neist on teatavate toimingute jaoks parem tehnika. Neid toiminguid saab rakendada paljudel viisidel, iga tehnikaga on plusse ja miinuseid.

Kui lause: If-lause võib aidata kaasa kohutavalt mahukale koodile, kui tingimuste tihedus on kõrge. Suur tihedus muudab ploki või meetodi tundlikuks. Kuid if-avaldustega kirjutatud kood on ka väga silumine, kuna arendaja saab igal real läbi astuda.

if (label1IsRequired) {
 silt1.värv = “punane”;
} veel {
 silt1.värv = “must”;
}
if (label2IsRequired) {
 silt2.värv = “punane”;
} veel {
 silt2.Värv = “must”;
}
if (label3IsRequired) {
 silt3.värv = “punane”;
} veel {
 silt3.Color = “must”;
}

Tingimuslik operaator: tingimusjuhiga operaator võib viia mõnele räigelt lõhenenud joonele, kui seda kasutatakse mitme if-lause asendamiseks. Manustatud tingimusjuhiga operaatorid muudavad koodi äärmise viimise korral väga raskesti loetavaks, testitavaks või silumiseks. Kõik tingimuslikele operaatoritele rasked plokid või meetodid on samuti väga kompaktsed, mis vähendab arendaja poolt skaneeritava koodi hulka.

healthIndicatorColor = (tervis == “hea”)? “Roheline”: (tervis == “õiglane”)? “Kollane”: (tervis == “halb”)? “Punane”: (tervis == “elu_tugi”)? “Oranž”: “lilla”;

Võimalik lahendus: Tingimuslikud operaatorid on kasulikud, kui nad asendavad väärtuste suure tiheduse, mis on seatud if-lausete kaudu rakendatud tingimuste alusel. Tingimuslikud operaatorid on hävitavad, kui nad asendavad isegi paar üksteisega seotud otsust. Tingimuslike operaatorite peamiseks sihtmärgiks on imperatiivid, mis sobivad hästi ühele reale, samas kui mitu lauset nõudvad tingimused on if-lausete domeen. If-lausete või tingimuslike operaatorite mis tahes koledat kasutamist tuleks parandada, et kasutada ühte neist konstruktidest. (Märkus: muutmine võib vajada olulist ümberreageerimist.)

if (tervis == “hea”) {
 healthIndicatorColor = “roheline”;
} muidu kui (tervis == “õiglane”) {
 healthIndicatorColor = “kollane”;
} else if (tervis == “halb”) {
 healthIndicatorColor = “punane”;
} veel kui (tervis == “elu_tugi”) {
 healthIndicatorColor = “oranž”;
} veel {
 healthIndicatorColor = “lilla”;
}
label1.Color = (label1IsRequired)? “Punane”: “must”;
label2.Color = (label2IsRequired)? “Punane”: “must”;
silt3.Color = (label3IsRequired)? “Punane”: “must”;

Mitu tagasisaatmist ja üks tagasisaatmine

Kaks argumentide juurde viivat stiili on mitu tagastamist ja ühekordne tagastamine. Lahkarvamused tekivad selles osas, kas meetoditel peaks olema üks tagastamisavaldus või on vastuvõetavad mitu tagastamisavaldust. Igal lähenemisel on positiivseid ja negatiivseid külgi.

Mitu tagastamise avaldust: mitme tagastamise avaldus võib aidata kaasa koodile, mida on raske mõista, jälgida ja testida. Mitme tagastamisega meetodid võivad olla lühemad kui ühe tagastamisega funktsioonid.

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

Üks tagasisaatmisavaldus: ühekordne tagasisaatmisaruanne võib viia pikkade meetoditeni. Kuid nendel protseduuridel on ühest punktist väljumine, mis lihtsustab testimist ja silumist.

SomeDataType someMethod () {
 SomeDataType retVal;
 // sadade või tuhandete ridade kood
 tagasi retVal;
}

Võimalik lahendus: mitmekordse tagastamise korral on koodi ebajärjekindla kasutamise korral keeruline aru saada, seda jälgida ja testida. Üksikud tagastuslaused viivad pikkade meetoditeni, kui neid jätkatakse koodide pikkuse teel. Neid tõmmatud vahemikke saab lühendada või vähemalt loetavaks muuta, kasutades ühe asemel mitu tagasitulekut. Üksikud tagastamised on täiesti vastuvõetavad, kui nad järgivad lühikesi koodijälgi. Üksiku või mitme tagastamise avalduse silmnähtav väärkasutamine tuleks fikseerida, et rakendada ühte neist stiilidest aktsepteeritud kasutusjuhtumit. (Märkus. Parandus võib vajada olulist ümberreageerimist.)

SomeDataType someMethod (param1, param2, param3) {
 if (param1 == null || param3 == null) {
 tagasi null;
 }
 
 SomeDataType retVal = null;
 if (param2! = null {
 retVal = param2;
 } else if (param1! = null) {
 retVal = param1;
 } ele if (param3! = null) {
 retVal = param3;
 }
 tagasi retVal;
}
SomeDataType someMethod (param1, param2) {
 SomeDataType retVal = null;
 jaoks (int i = 0; i  if (param1 [i] .equals (param2)) {
 retVal = param1 [i];
 vaheaeg;
 }
 }
 tagasi retVal;
} Loobumise jätkamine ja jätkamine

Paus ja jätka konstruktsioone on intensiivsete arutelude objektiks. Argumendi ühel küljel väidavad arendajad, et katkestamine ja jätkamine võib juhtimisvoogu lihtsustada. Teised programmeerijad väidavad, et need funktsioonid raskendavad programmi loogikat. Murdmist ja jätkamist saab kindlasti kasutada koodi lihtsustamiseks või keerukamaks muutmiseks. Neid jooni võib märgata.

Katkesta ja jätka kasutamist: elemendid võivad koodi lihtsustada, kuid võivad neid ka asjatult keeruliseks muuta.

SomeDataType someMethod (param1, param2) {
 SomeDataType retVal = null;
 jaoks (int i = 0; i  if (param1 [i] == null) {
 jätka;
 }
 if (param1 [i] .equals (param2)) {
 retVal = param1 [i];
 vaheaeg;
 }
 }
 tagasi retVal;
}
SomeDataType someMethod (andmed, param1) {
 SomeDataType retVal = null;
 tee midagi:
 jaoks (int i = 0; i  if (i> = andmepikkus) {
 vaheaeg;
 }
 if (andmed [i] .ekvivalendid (para1)) {
 retVal = andmed [i];
 } veel {
 jätka;
 }
 }
if (retVal == null) {
 andmed - refreshData ();
 Goto dosometing;
 }
tagasi retVal;
}

Võimalik lahendus: enamik arendajaid väidab, et kood peaks juhtimisvoogude jaoks kasutama lihtsaid mehhanisme. Millised konkreetsed mehhanismid on lihtsad, on arutelu allikas. See argument muutub palju vähem kuumaks, kui igat instrumenti kasutatakse laialdaselt aktsepteeritud viisidel. Lubatud lähenemisviisid eksisteerivad vaheajaks ja jätkuvad. Pidage kinni neist tavadest, et vältida lahkarvamusi ja lihtsustada kontrollivoogu. Kõik kontrollimeetmed, mis neid norme rängalt rikuvad, tuleks parandada ilma aruteluta.

SomeDataType someMethod (andmed, param1) {
 SomeDataType retVal = null;
 jaoks (int i = 0; i  if (andmed [i] == null) {
 jätka; // jäta ülejäänud silmus vahele
 }
 if (andmed [i] .ekvivalent (param2)) {
 retVal = andmed [i];
 vaheaeg; // ärge enam silmuseid tehke
 }
 }
 tagasi retVal;
}

Kaitsvad erandid

Erandid on vahend probleemile viitamiseks või tulevase probleemi ära hoidmiseks. Millistele peavaludele tuleks tähelepanu pöörata või mida need ettevaatusabinõud ära hoiavad, on äge arutelu teema. Erimeelsuse ühest küljest väidavad kodeerijad, et ulatuslikud kaitse-erandid väldivad vigu ja muudavad nende asukoha hõlpsalt tuvastatavaks. See kaitseminister võib aga muuta koodi ülespuhutud ja raskesti mõistetavaks, nagu mõned programmeerijad on väitnud. Arendajatel, kes on arutelu mõlemal poolel, on punkt. Kaitsvatel eranditel on nii plusse kui ka kahju.

Kaitsvate erandite eelised ja puudused: Kaitset võimaldavate erandite kasutamisel saab kaitset vigade ja muude probleemide eest minimaalsete puudustega kaitsta. Need vead muutuvad suuremaks, kui tehnika on valimatu.

void someMethod (param1, param2) {
 if (param1 == null || param2 == null) {
 viska uus ArgumentNullException (“Üks või mitu parameetrit on puudu”);
 }
 // tehke metoodikat
}
void someMethod (param1, param2) {
 // kümneid kaitselisi kontrolle ...
 // tehke ülejäänud meetod
}

Võimalik lahendus: kaitseotstarbeliste erandite puudused on kõige väiksemad, kui neid kasutatakse aktsepteeritud viisil. Kõigist nendest tavadest kõrvalekalduvate tehnikate kasutuselevõttu tuleks parandada, kui pole esitatud mõjuvaid põhjuseid.

public void someMethod (param1, param2) {
 // kontrollige kõiki parameetreid avalikul meetodil
 if (param1 == null || param2 == null) {
 viska uus ArgumentNullException (“Üks või mitu parameetrit on puudu”);
 }
 
 // hoiab ära valed andmed
 if (! isValid (param1) ||! isValid (param2)) {
 viska uus InvalidParameterException (“Üks või mitu parameetrit on kehtetud”);
 }
 
 // teha midagi parameetritega
}

Tõmba otsad kokku

Neid koodikonstruktsioone ja tehnikaid kasutavad nii head kui ka halvad arendajad. Programmeerijad on inimesed. Inimestel on kalduvusi. Need kalduvused avalduvad koodina. Mõnikord sunnib arendaja impulss kirjutama koodi, mida teised kodeerijad õigustatult kritiseerivad. Arendaja, keda vaevatakse, pole tingimata halb programmeerija. Teda kritiseeriv kooder pole tingimata hea arendaja. Mõlemat inimest on ühel hetkel nende eelistused tõenäoliselt eksinud. Need soovid ei tohiks viia selleni, et areng degenereerub üksteise otsa lõputuks solvumiste vooluks. Pigem peaksid programmeerijad üksteise koodi üle vaatama, piirama oma lahingud kõige halvemate lõikudega ja nõustuma lahendama teatud argumendid ülaltoodud reeglite abil.