Revisions del codi: causes habituals de violacions extremes i evitar arguments per solucionar-les

S’estiren ganivets. Les fulles s’afilen per conflicte. Hi ha una disputa entre els desenvolupadors. Les passions dels programadors no són despertades per un programari defectuós, sinó per un codi extremadament precís o extens. Aquestes línies indiquen un hack. Qualsevol programador que no estigui d'acord és aficionat. Només a un novell se li acudirien mètodes i blocs clarament contraris al bon gust. No obstant això, diferents preferències, no les lleis de la natura, són la font d’aquest conflicte i vitriol. L’odi entre desenvolupadors, en aquest cas, és el resultat de diferents tendències al comerç de concisió amb diferents propòsits. Aquests objectius i la tendència cap a ells són diferents per a cada desenvolupador, cosa que provoca conflictes constants en determinades àrees. Un d’aquests llocs és el codi detallat o minúscul. Per minimitzar la lluita, un equip pot utilitzar ressenyes de codi per ressaltar els segments més flagrants, i el grup pot discutir sobre aquestes parts en lloc de discutir sobre cada línia i bloc d'una base de codi.

És probable que determinades construccions o tècniques de codi resultin en infraccions extremes i generin arguments sobre com corregir aquestes infraccions. L'eliminació d'aquests abusos condueix a arguments violents. Aquestes diferències d'opinió es poden resoldre o, com a mínim, mitigar-les per a les característiques i tècniques lingüístiques particulars que s'enumeren a continuació.

Operador condicional vs. Si afirmació

Els elements lingüístics, l’operador condicional i l’afirmació if condueixen a arguments, amb diversos camps argumentant que cadascun és la tècnica superior per a determinades operacions. Aquestes accions es poden implementar de diverses maneres, tenint cada tècnica avantatges i desavantatges.

Instrucció if: la sentència if pot contribuir a un codi tremendament gran si les condicions són altes. Una alta densitat fa que un bloc o un mètode sembli inflat. No obstant això, el codi escrit amb instruccions if també és molt depurable perquè un desenvolupador pot passar per cada línia.

if (label1IsRequired) {label1.Color = "vermell"; } else {label1.Color = "negre"; }
if (label2IsRequired) {label2.Color = "vermell"; } else {label2.Color = "negre"; }
if (label3IsRequired) {label3.Color = "vermell"; } else {label3.Color = "negre"; }

Operador condicional: l'operador condicional pot produir línies molt curtes quan s'utilitza com a substitut de diverses sentències if. Els operadors condicionals incrustats fan que el codi sigui extremadament difícil de llegir, provar o depurar. Qualsevol bloc o mètode que contingui molts operadors condicionals també és molt compacte, cosa que redueix la quantitat de codi que un desenvolupador ha d’escanejar.

healthIndicatorColor = (salut == "bona")? "Verd": (salut == "just")? "Groc": (salut == "dolent")? "Vermell": (Salut == "Suport vital")? "Taronja": "porpra";

Possible solució: els operadors condicionals són avantatjosos quan substitueixen una alta densitat de valors en funció de les condicions implementades per les sentències if. Els operadors condicionals són destructius si fins i tot substitueixen algunes decisions imbricades. Els imperatius que encaixen de manera llegible en una línia són un objectiu principal per als operadors condicionals, mentre que les condicions que requereixen diverses línies són el domini de les sentències if. Qualsevol ús escandalós de les afirmacions o operadors condicionals s'hauria de corregir per proporcionar un ús adequat d'alguna d'aquestes construccions. (Nota: els canvis poden requerir un redisseny important).

if (salut == “Bona”) {healthIndicatorColor = "verd"; } else if (salut == "Just") {healthIndicatorColor = "groc"; } else if (salut == “pobra”) {healthIndicatorColor = "vermell"; } else if (health == “life_support”) {healthIndicatorColor = "taronja"; } else {healthIndicatorColor = "morat"; }
etiqueta1.Color = (etiqueta1ÉS NECESSARI)? "Negre vermell"; label2.Color = (label2IsRequired)? "Negre vermell"; label3.Color = (label3ISRequired)? "Negre vermell";

Múltiples declaracions de devolució vs. Una declaració de devolució

Dos estils particulars que generen arguments són els retorns múltiples i els retorns individuals. Hi ha desacord sobre si els mètodes han de tenir una declaració de retorn o si són múltiples les declaracions de retorn. Cada enfocament té avantatges i desavantatges.

Múltiples declaracions de retorn: diverses declaracions de retorn es poden afegir a un codi que és difícil d'entendre, seguir i provar. No obstant això, els mètodes amb múltiples retorns poden ser més curts que les funcions amb un retorn únic.

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

Una declaració de retorn: una única declaració de retorn pot conduir a mètodes llargs. No obstant això, aquests procediments tenen un punt únic que facilita la prova i la depuració.

SomeDataType someMethod () {SomeDataType retVal; // Centenars o milers de línies de codi retornen retVal; }

Solució possible: diverses devolucions fan que el codi sigui difícil d’entendre, seguir i provar si s’utilitza de manera incoherent. Les declaracions de devolució individuals generen mètodes llargs si són processats per seccions llargues de codi. Aquests períodes de temps ampliats es poden escurçar o, almenys, fer-los llegibles mitjançant l'ús de diverses declaracions de retorn en lloc d'una. Les devolucions individuals són perfectament acceptables si segueixen breus trossos de codi. Qualsevol ús indegut aparent d’una declaració de devolució única o de devolucions múltiples s’hauria d’abordar per aplicar un cas d’ús acceptat per a qualsevol d’aquests estils. (Nota: la correcció pot requerir un redisseny important.)

SomeDataType someMethod (param1, param2, param3) {if (param1 == null || param3 == null) {return null; } SomeDataType retVal = null; if (param2! = null {retVal = param2;} else if (param1! = null) {retVal = param1;} ele if (param3! = null) {retVal = param3;} return retVal;}
SomeDataType someMethod (param1, param2) {SomeDataType retVal = null; per a (int i = 0; i

Les construccions de ruptura i continuació són objecte d’un intens debat. Per una banda de l’argument, els desenvolupadors argumenten que el trencament i la continuïtat poden simplificar el flux de control. Altres programadors afirmen que aquestes funcions compliquen la lògica d’un programa. Break and Continue definitivament es pot utilitzar per simplificar o complicar el codi. Aquestes línies es poden descobrir.

Trencar i continuar utilitzant: els elements poden simplificar el codi, però també el poden complicar innecessàriament.

SomeDataType someMethod (param1, param2) {SomeDataType retVal = null; per a (int i = 0; i
SomeDataType someMethod (dades, param1) {SomeDataType retVal = null; fer alguna cosa: for (int i = 0; i = longitud.dades) {interrupció; } if (data [i] .equals (param1)) {retVal = data [i]; } else {continue; }}
if (retVal == null) {data - refreshData (); anar a alguna cosa; }
tornar retVal; }

Possible solució: la majoria dels desenvolupadors creuen que el codi hauria d’utilitzar mecanismes senzills per controlar el flux. Quins mecanismes específics són simples és la font del debat. Aquest argument es fa molt menys calent quan cada instrument s’utilitza de manera generalment acceptada. Existeixen enfocaments acceptats per a la pausa i la continuació. Seguiu aquestes convencions per evitar desacords i simplificar el flux de control. Els controls que violin violentament aquestes normes haurien de corregir-se sense debat.

SomeDataType someMethod (dades, param1) {SomeDataType retVal = null; per a (int i = 0; i

Excepcions defensives

Les excepcions són un mitjà per indicar un problema o prevenir un problema futur. Quins mals de cap s’han d’indicar o evitar amb quines parts del codi són objecte d’un acalorat debat. En un extrem del desacord, els programadors argumenten que les excepcions defensives consistents eviten errors i faciliten la localització. Tanmateix, aquesta llista de defensa pot fer que el codi sigui inflat i difícil d’entendre, tal com han argumentat alguns programadors. Els desenvolupadors d’ambdues parts del debat tenen un punt. Les excepcions defensives tenen avantatges i desavantatges.

Avantatges i desavantatges de les excepcions defensives: la protecció contra errors i altres problemes es pot evitar amb desavantatges mínims mitjançant excepcions defensives. Aquestes mancances s’agreugen quan la tècnica és indiscriminada.

void someMethod (param1, param2) {if (param1 == null || param2 == null) {llança una nova excepció ArgumentNullEx ("Falten un o més paràmetres"); } // fer mètodes}
void someMethod (param1, param2) {// dotzena de controls de defensa ... .. // feu la resta del mètode}

Possible solució: les deficiències excepcionals defensives són més petites quan s’utilitzen en usos acceptats. Qualsevol ús de la tècnica que es desviï d’aquestes convencions s’ha de corregir tret que es doni una raó convincent.

public void someMethod (param1, param2) {// comprova tots els paràmetres d’un mètode públic si (param1 == null || param2 == null) {llança una nova excepció ArgumentNullEx ("Falten un o més paràmetres"); } // Resoleu els problemes causats per dades no vàlides si (! IsValid (param1) ||! IsValid (param2)) {Llanceu una nova InvalidParameterException ("Un o més paràmetres no són vàlids"); } // fer alguna cosa amb paràmetres}

Embolicar

Aquestes construccions i tècniques de codi les utilitzen tant els desenvolupadors bons com els dolents. Els programadors són persones. La gent té tendències. Aquestes tendències es manifesten en el codi. De vegades, l’impuls d’un desenvolupador el porta a escriure codi que altres programadors tenen raó en criticar. El desenvolupador criticat no és necessàriament un mal programador. El programador que el critica no és necessàriament un bon desenvolupador. Probablement, ambdues persones van ser enganyades per les seves preferències en algun moment. Aquests desitjos no haurien de portar el desenvolupament a degenerar en un flux sense fi d’insults que es llançaven els uns als altres. Més aviat, els programadors haurien de revisar-se el codi, limitar les seves lluites a les pitjors parts i acceptar resoldre certs arguments basant-se en les regles esmentades anteriorment.