Koda pārskati: biežākie ārkārtēju pārkāpumu avoti un kā izvairīties no argumentiem par to labošanu

Naži tiek uzzīmēti. Asmeņi ir asināti konflikta dēļ. Starp izstrādātājiem plosās strīds. Kodētāju aizraušanās ir iekaist nevis ar kļūdainu programmatūru, bet gan pārmērīgi kodolīgu vai izteiktu kodu. Šīs līnijas ir uzlaušanas pazīmes. Ikviens programmētājs, kurš nepiekrīt, ir amatieris. Tikai neofīts ražotu metodes un blokus, kas tik skaidri pārkāpj labu gaumi. Tomēr atšķirīgās izvēles, nevis dabas likumi, ir šī konflikta un vitriola avots. Naids starp izstrādātājiem šajā gadījumā ir dažādu noslieci uz tirdzniecības kodolīgumu dažādu mērķu rezultāts. Šie mērķi un tieksme uz tiem katram izstrādātājam ir atšķirīgi, izraisot pastāvīgu konfliktu noteiktās jomās. Viena no šādām vietām ir vārdains vai pareizais kods. Lai samazinātu cīņu, komanda var izmantot kodu pārskatus, lai izceltu visbriesmīgākos segmentus, un grupa var strīdēties par šīm daļām, tā vietā strīdoties par katru koda bāzes līniju un bloku.

Atsevišķas koda konstrukcijas vai paņēmieni, iespējams, radīs galējus pārkāpumus un radīs argumentus par šo pārkāpumu labošanu. Šo pārkāpumu novēršana izraisa intensīvus argumentus. Šīs domstarpības var atrisināt vai vismaz samazināt dekalatūru attiecībā uz zemāk uzskaitītajām īpašajām valodu iezīmēm un paņēmieniem.

Nosacīts operators salīdzinājumā ar paziņojumu

Lingvistiskie elementi, nosacītais operators un if-izteikums, rada argumentus, dažādās nometnēs apgalvojot, ka katra no tām ir augstāks paņēmiens noteiktām operācijām. Šīs darbības var īstenot neskaitāmos veidos, katram paņēmienam radot priekšrocības un trūkumus.

Ja paziņojums: Ja apgalvojums var izraisīt briesmīgi apjomīgu kodu, ja apstākļu blīvums ir augsts. Augsts blīvums padara bloku vai metodi šķietamu. Tomēr kods, kas rakstīts ar if-izteikumiem, arī ir ļoti atkļūdojams, jo izstrādātājs var iziet cauri katrai rindai.

if (label1IsRequired) {
 label1.Color = “sarkans”;
} cits {
 label1.Color = “melns”;
}
ja (label2IsRequired) {
 label2.Color = “sarkans”;
} cits {
 label2.Color = “melns”;
}
ja (label3IsRequired) {
 etiķete3.Color = “sarkans”;
} cits {
 etiķete3.Krāsa = “melna”;
}

Nosacīts operators: nosacīts operators var novest pie dažām šķietami īsām rindām, ja to izmanto kā vairāku if-apgalvojumu aizstājēju. Iegultie nosacītie operatori padara kodu ļoti grūti lasāmu, pārbaudāmu vai atkļūdotu, ja tas tiek izmantots galējībā. Arī jebkurš bloķēšana vai metode, kas ir smaga nosacītajiem operatoriem, ir ļoti kompakta, samazinot koda daudzumu, kas izstrādātājam ir jānoskenē.

healthIndicatorColor = (veselība == “laba”)? “Zaļš”: (veselība == “godīga”)? “Dzeltens”: (veselība == “slikta”)? “Sarkans”: (veselība == “dzīvības_atbalsts”)? “Oranža”: “violeta”;

Potenciālā izšķirtspēja: nosacīti operatori ir izdevīgi, ja tie aizvieto lielu vērtību blīvumu, kas noteikts, pamatojoties uz nosacījumiem, kas ieviesti, izmantojot if-paziņojumus. Nosacīti operatori ir destruktīvi, aizstājot pat pāris lēmumus, kas iestrādāti savā starpā. Imperatori, kas atkārtoti pielāgojami vienā rindā, ir galvenais mērķis nosacītajiem operatoriem, savukārt apstākļi, kuriem ir vajadzīgas vairākas līnijas, ir if-apgalvojumi. Jāizlabo jebkāds drausmīgs if-apgalvojumu vai nosacītu operatoru lietojums, lai piemērotu viena no šīm konstrukcijām atbilstošu izmantošanu. (Piezīme. Pārveidošanai, iespējams, būs nepieciešama ievērojama reakcija.)

ja (veselība == “laba”) {
 healthIndicatorColor = “zaļš”;
} cits, ja (veselība == “godīga”) {
 healthIndicatorColor = “dzeltens”;
} cits, ja (veselība == “slikta”) {
 healthIndicatorColor = “sarkans”;
} cits, ja (veselība == “dzīvības_atbalsts”) {
 healthIndicatorColor = “oranža”;
} cits {
 healthIndicatorColor = “purpursarkana”;
}
label1.Color = (label1IsRequired)? “Sarkans”: “melns”;
label2.Color = (label2IsRequired)? “Sarkans”: “melns”;
label3.Color = (label3IsRequired)? “Sarkans”: “melns”;

Vairāki atgriešanās paziņojumi pret vienu atgriešanās paziņojumi

Divi īpaši stili, kas izraisa argumentus, ir daudzkārtēja atgriešanās un viena atgriešanās. Rodas domstarpības par to, vai metodēm vajadzētu būt vienam atgriešanās paziņojumam vai arī vai ir pieņemami vairāki atgriešanās paziņojumi. Katrai pieejai ir pozitīvas un negatīvas.

Vairāki atgriešanās paziņojumi: Vairāku atgriešanas paziņojumi var dot ieguldījumu kodā, kuru ir grūti saprast, ievērot un pārbaudīt. Tomēr metodes ar vairākkārtēju atdošanu var būt īsākas nekā funkcijas ar vienu atdevi.

SomeDataType someMethod (param1, param2, param3) {
 SomeDataType retVal;
 if (param1 == nulle) {
 retVal = nulle
 }
 if (retVal == null) {
 atgriešanās retVal;
 }
 
 if (param2! = null) {
 retVal = param2;
 }
 if (retVal.Equals (param2)) {
 atgriešanās retVal;
 }
 
 retVal = param3;
 atgriešanās retVal;
}

Viens paziņojums par atgriešanos: viens atgriešanās paziņojums var radīt garas metodes. Tomēr šīm procedūrām ir viena punkta izeja, kas vienkāršo testēšanu un atkļūdošanu.

SomeDataType someMethod () {
 SomeDataType retVal;
 // simtiem vai tūkstošiem līniju koda
 atgriešanās retVal;
}

Potenciālā izšķirtspēja: vairākkārtēja atgriešana apgrūtina koda izpratni, sekošanu un pārbaudi, ja tie tiek izmantoti nekonsekventi. Atsevišķi atgriešanās paziņojumi noved pie garām metodēm, kad tās tiek veiktas ar gariem koda posmiem. Šos izvilktos posmus var saīsināt vai vismaz padarīt tos salasāmus, viena vietā izmantojot vairākus atgriešanās paziņojumus. Atsevišķa atgriešana ir pilnīgi pieņemama, ja tā seko īsiem koda traktātiem. Jāuzlabo jebkāda acīmredzama viena atgriešanās paziņojuma vai vairāku deklarāciju ļaunprātīga izmantošana, lai piemērotu akceptētu lietošanas gadījumu vienam no šiem stiliem. (Piezīme: labošanai var būt nepieciešama ievērojama reakcija.)

SomeDataType someMethod (param1, param2, param3) {
 if (param1 == nulle || param3 == null) {
 atgriezt null;
 }
 
 SomeDataType retVal = nulle;
 if (param2! = nulle {
 retVal = param2;
 } cits, ja (param1! = nulle) {
 retVal = param1;
 } ele if (param3! = nulle) {
 retVal = param3;
 }
 atgriešanās retVal;
}
SomeDataType someMethod (param1, param2) {
 SomeDataType retVal = nulle;
 priekš (int i = 0; i  if (param1 [i] .equals (param2)) {
 retVal = param1 [i];
 pārtraukums;
 }
 }
 atgriešanās retVal;
} Pārtraukt un turpināt lietot cilpas

Pārtraukums un turpināmās konstrukcijas ir intensīvu diskusiju priekšmets. Argumenta vienā pusē izstrādātāji apgalvo, ka pārtraukšana un turpināšana var vienkāršot vadības plūsmu. Citi programmētāji apgalvo, ka šīs funkcijas sarežģī programmas loģiku. Pārtraukt un turpināt noteikti var izmantot koda vienkāršošanai vai sarežģīšanai. Šīs līnijas var pamanīt.

Pārtraukt un turpināt izmantošanu: elementi var vienkāršot kodu, taču tie tos var arī nevajadzīgi sarežģīt.

SomeDataType someMethod (param1, param2) {
 SomeDataType retVal = nulle;
 priekš (int i = 0; i  if (param1 [i] == nulle) {
 Turpināt;
 }
 if (param1 [i] .equals (param2)) {
 retVal = param1 [i];
 pārtraukums;
 }
 }
 atgriešanās retVal;
}
SomeDataType someMethod (dati, 1. punkts) {
 SomeDataType retVal = nulle;
 dari kaut ko:
 priekš (int i = 0; i  if (i> = data.length) {
 pārtraukums;
 }
 if (dati [i] .equals (param1)) {
 retVal = dati [i];
 } cits {
 Turpināt;
 }
 }
if (retVal == null) {
 dati - refreshData ();
 veikt dozēšanu;
 }
atgriešanās retVal;
}

Potenciālā izšķirtspēja: vairums izstrādātāju apgalvo, ka kodam vadības plūsmai jāizmanto vienkārši mehānismi. Diskusiju avots ir tas, kuri īpašie mehānismi ir vienkārši. Šis arguments kļūst daudz karstāks, ja katru instrumentu izmanto plaši pieņemtos veidos. Pieņemtās pieejas pastāv pārtraukumā un turpinās. Ievērojiet šīs konvencijas, lai novērstu domstarpības un vienkāršotu kontroles plūsmu. Jebkuri kontroles līdzekļi, kas acīmredzami pārkāpj šos standartus, būtu jālabo bez debatēm.

SomeDataType someMethod (dati, 1. punkts) {
 SomeDataType retVal = nulle;
 priekš (int i = 0; i  if (dati [i] == nulle) {
 Turpināt; // izlaist pārējo cilpu
 }
 if (dati [i] .equals (param2)) {
 retVal = dati [i];
 pārtraukums; // nedariet vairs cilpu. b / c es esmu darījis
 }
 }
 atgriešanās retVal;
}

Aizsardzības izņēmumi

Izņēmumi ir līdzeklis, lai norādītu uz problēmu vai novērstu nākotnes problēmu. Par kādām galvassāpēm vajadzētu norādīt vai novērst tās, kuras koda daļas ir asas debašu tēma. Vienā domstarpību galā kodētāji apgalvo, ka plaši aizsardzības izņēmumi novērš kļūdas un padara tās viegli atrodamas. Tomēr šis veļas aizsardzības saraksts var padarīt kodu uzpūstu un grūti saprotamu, kā apgalvoja daži programmētāji. Izstrādātājiem abās debašu pusēs ir punkts. Aizsardzības izņēmumiem ir gan ieguvumi, gan trūkumi.

Aizsardzības izņēmumu priekšrocības un trūkumi: Aizsardzību pret kļūdām un citām problēmām var aizsargāt, izmantojot minimālus trūkumus, izmantojot aizsardzības izņēmumus. Šie trūkumi kļūst vēl lielāki, ja tehnika ir izšķirīga.

void someMethod (param1, param2) {
 if (param1 == nulle || param2 == null) {
 mest jauno ArgumentNullException (“Trūkst viena vai vairāku parametru”);
 }
 // darīt metodi sīkumi
}
void someMethod (param1, param2) {
 // desmitiem līniju aizsardzības pārbaudēm ...
 // veiciet pārējo metodi
}

Potenciālais risinājums: Aizsardzības izņēmumu trūkumi ir mazāki, ja tos izmanto pieņemtā veidā. Jāizlabo jebkura tehnikas izmantošana, kas atšķiras no šīm konvencijām, ja vien nav norādīts pārliecinošs iemesls.

public void someMethod (param1, param2) {
 // pārbaudiet katru parametru publiskajā metodē
 if (param1 == nulle || param2 == null) {
 mest jauno ArgumentNullException (“Trūkst viena vai vairāku parametru”);
 }
 
 // novērš problēmas, kas radušās pēc nederīgiem datiem
 if (! isValid (param1) ||! isValid (param2)) {
 mest jaunu InvalidParameterException (“Viens vai vairāki parametri nav derīgi”);
 }
 
 // dari kaut ko ar parametriem
}

Satīt

Šīs koda konstrukcijas un paņēmienus izmanto gan labie, gan sliktie izstrādātāji. Programmētāji ir cilvēki. Cilvēkiem ir tendences. Šīs tieksmes izpaužas kodā. Reizēm izstrādātāja impulss liek viņam uzrakstīt kodu, kuru citi kodētāji pamatoti kritizē. Izstrādātājam, kurš tiek nomocīts, ne vienmēr ir slikts programmētājs. Kodētājs, kas viņu kritizē, nebūt nav labs izstrādātājs. Abas personas, iespējams, vienā brīdī ir maldinājušās pēc viņu vēlmēm. Šīs vēlmes nedrīkst novest pie tā, ka attīstība deģenerējas nebeidzamā apvainojumu straumē, kas savijas viens pret otru. Programmētājiem drīzāk ir jāpārskata viens otra kods, jāierobežo cīņas līdz sliktākajām sadaļām un jāpiekrīt nokārtot noteiktus argumentus, izmantojot iepriekš izklāstītos noteikumus.