coding-style - trucos - como usar el bloque de comandos en minecraft pe

¿Qué poner en el bloque IF y qué poner en el bloque ELSE?

Question

Esta es una pregunta de estilo menor, pero cada bit de legibilidad que agregue a su código cuenta.

Entonces si tienes:

if (condition) then
{
// do stuff
}
else
{
// do other stuff
}

¿Cómo decides si es mejor así o así?

 if (!condition) then
{
// do other stuff
{
else
{
// do stuff
}

Mi heurística es:

1. Mantenga la condición positiva (menos cálculo mental cuando la lea)
2. Pon la ruta más común en el primer bloque

Answer 1

1. poner el camino común primero
2. convierte cheking negativo en positivo ( !full == empty )

Answer 2

Como regla general, si uno es significativamente más grande que el otro, hago que el más grande sea el bloque if .

Answer 3

Creo que para una sola variable, el operador no es lo suficientemente simple y los problemas de denominación comienzan a ser más relevantes.

Nunca nombre una variable not_X, si es necesario use un diccionario de sinónimos y encuentre un opuesto. He visto un montón de código horrible como

if (not_dead) {
} else {
}

en lugar de lo obvio

if (alive) {
} else {
}

Entonces puede usar sanamente (muy legible, sin necesidad de invertir los bloques de código)

if (!alive) {
} else {
}

Si estamos hablando de más variables, creo que la mejor regla es simplificar la condición. Después de un tiempo, los proyectos tienden a tener condiciones como:

if (dead || (!dead && sleeping)) {
} else {
}

Lo que se traduce a

if (dead || sleeping) {
} else {
}

Siempre preste atención a cómo se ven las condiciones y cómo simplificarlas.

Answer 4

Cuando veo la validación de datos, trato de hacer que mis condiciones sean "listas blancas", es decir, pruebo lo que voy a aceptar:

if DataIsGood() then
DoMyNormalStuff
else
TakeEvasiveAction

En lugar de al revés, que tiende a degenerar en:

if SomeErrorTest then
TakeSomeEvasiveAction
else if SomeOtherErrorCondition then
CorrectMoreStupidUserProblems
else if YetAnotherErrorThatNoOneThoughtOf then
DoMoreErrorHandling
else
DoMyNormalStuff

Answer 5

Depende de tu flujo Para muchas funciones, usaré precondiciones:

bool MyFunc(variable) {
if (variable != something_i_want)
return false;
// a large block of code
// ...
return true;
}

Si necesito hacer algo en cada caso, usaré un formato if (positive_clause) {} else {} .

Answer 6

Dos citas de libros de texto (contradictorias):

Pon la cláusula más corta de un if / else en la parte superior

- Allen Holub, "Suficiente cuerda para tirarse en el pie", p52

Coloque el caso normal después del if en lugar de después del else

--Steve McConnell, "Code Complete, 2nd ed.", P356

Answer 7

El software es captura de conocimiento. Estás codificando el conocimiento de alguien sobre cómo hacer algo.

El software debe ajustarse a lo que es "natural" para el problema. En caso de duda, pregúntele a otra persona y vea lo que la gente realmente dice y hace.

¿Qué pasa con la situación donde el caso "común" es no hacer nada? Entonces que

if( common ) {
// pass
}
else {
// great big block of exception-handling folderol
}

¿O haces esto?

if( ! common ) {
// great big block of except-handling folderol
}

La regla "siempre positiva" no es realmente lo que quieres primero. Desea observar reglas más parecidas a las siguientes.

1. Siempre natural: debe leerse como inglés (o el idioma común en su organización).
2. Donde sea posible, primero los casos comunes, para que parezcan comunes.
3. Donde sea posible use una lógica positiva; La lógica negativa se puede usar cuando se dice comúnmente de esa manera o cuando el caso común es "no hacer nada".

Answer 8

Estoy de acuerdo con Oli en usar una cláusula positiva si es posible.

Por favor, nunca hagas esto:

if (somePositiveCondition)
else {
//stuff
}

Solía ​​ver esto mucho en un lugar donde trabajaba y solía preguntarme si uno de los codificadores no entendía cómo no funciona ...

Answer 9

La predicción de la rama Intel Pentium realiza una precarga de las instrucciones para el caso "si". Si, por el contrario, sigue la rama "else": tiene el color de la tubería de instrucciones, causando un bloqueo.

Si le importa mucho el rendimiento: coloque el resultado más probable en la cláusula ''si''.

Personalmente lo escribo como

if (expected)
{
//expected path
}
else
{
//fallback other odd case
}

Answer 10

Para mí, depende de la condición, por ejemplo:

if (!PreserveData.Checked)
{ resetfields();}

Tiendo a hablar conmigo mismo sobre lo que quiero que sea la lógica y la codifico con la pequeña voz en mi cabeza.

Answer 11

Por lo general, puede hacer que la condición sea positiva sin cambiar los bloques if / else.

Cambio

 if (!widget.enabled()) {
// more common
} else {
// less common
}

a

 if (widget.disabled()) {
// more common
} else {
// less common
}

Answer 12

Prefiero la primera. La condición debe ser lo más simple posible y debería ser bastante obvio, lo que es más simple fuera de condición y condición.

Answer 13

Prefiero poner el camino más común primero, y creo firmemente en la reducción de anidamiento, por lo que voy a romper, continuar o regresar en lugar de elsing siempre que sea posible. Generalmente prefiero probar contra condiciones positivas, o invertir [y nombrar] condiciones negativas como positivas.

if (condition)
return;
DoSomething();

He descubierto que al reducir drásticamente el uso de else, mi código es más legible y mantenible, y cuando tengo que usar else, casi siempre es un excelente candidato para una declaración de cambio más estructurada.

Answer 14

Sé que esto no es exactamente lo que estás buscando, pero ... Muchos desarrolladores usan una "cláusula de guardia", es decir, una declaración negativa "si" que rompe el método lo antes posible. En ese momento, no hay otro "realmente".

Ejemplo:

if (blah == false)
{
return; // perhaps with a message
}
// do rest of code here...

¡¡¡Hay algunos tipos de c / c ++ / ensambladores hard-core por ahí que te dirán que estás destruyendo tu CPU !!! (en muchos casos, los procesadores favorecen la afirmación "verdadera" y tratan de "precapturar" lo siguiente a hacer ... así que teóricamente cualquier condición "falsa" vaciará la tubería y se irá microsegundos más lentamente).

En mi opinión, estamos en el punto donde el código "mejor" (más comprensible) gana en microsegundos de tiempo de CPU.

Answer 15

Si el código es verificar una condición de error, prefiero poner ese código primero, y el segundo código "exitoso"; conceptualmente, esto mantiene una llamada de función y su código de comprobación de errores juntos, lo cual tiene sentido para mí porque están relacionados. Por ejemplo:

 if (!some_function_that_could_fail())
{
// Error handling code
}
else
{
// Success code
}

Answer 16

Si tiene condiciones tanto verdaderas como falsas, optaría por un condicional positivo: esto reduce la confusión y, en general, creo que hace que su código sea más fácil de leer.

Por otro lado, si está utilizando un lenguaje como Perl, y particularmente si su condición falsa es una condición de error o la condición más común, puede usar la estructura ''a menos'', que ejecuta el bloque de código a menos que la condición es verdadero (es decir, el opuesto de si):

unless ($foo) {
$bar;
}

Answer 17

Siempre debe colocar el caso más probable primero. Además de ser más legible, es más rápido. Esto también se aplica a declaraciones de cambio.

Answer 18

Siempre guardo lo más probable primero.

En Perl tengo una estructura de control adicional para ayudar con eso. El inverso de if.

unless (alive) {
go_to_heaven;
} else {
say "MEDIC";
}

Answer 19

Soy horrible cuando se trata de cómo configuro las declaraciones. Básicamente, lo configuré en función de lo que estoy buscando, lo que hace que todo sea diferente.

if (userinput = null) {
explodeViolently ();
} else {
en realidad hacer cosas;
}

o tal vez algo así como

if (1 + 1 = 2) {
hacer cosas;
} else {
explodeViolently ();
}

¿Qué sección de la declaración if / else realmente hace cosas para mí es un mal hábito mío?

Answer 20

En primer lugar, dejemos de lado las situaciones en las que es mejor evitar el uso de "else" en primer lugar (espero que todos estén de acuerdo en que tales situaciones existen y que la determinación de tales casos probablemente debería ser un tema separado).

Entonces, supongamos que debe haber una cláusula "else".

Creo que la legibilidad / comprensión impone al menos tres requisitos o reglas clave, que desafortunadamente a menudo compiten entre sí:

1. Cuanto más corto sea el primer bloque (el bloque "si"), más fácil es captar todo el constructo "si-no". Cuando el bloque "if" es lo suficientemente largo, es demasiado fácil ignorar la existencia del bloque "else".

2. Cuando las rutas "if" y "else" son lógicamente asimétricas (por ejemplo, "procesamiento normal" vs. "procesamiento de errores"), en una construcción independiente "if-else" realmente no importa mucho qué camino es primero y cuál es el segundo . Sin embargo, cuando hay múltiples construcciones "if-else" en proximidad entre sí (incluida la anidación), y cuando todas esas construcciones "if-else" tienen una asimetría del mismo tipo, es cuando es muy importante organizar esas rutas asimétricas consecuentemente.

   De nuevo, puede ser "si ... ruta normal ... más ... ruta anormal" para todos, o "si ... ruta anormal ... más ... ruta normal" para todos, pero no debería ser una mezcla de estas dos variantes.

   Con todas las demás condiciones iguales, poner el camino normal primero es probablemente más natural para la mayoría de los seres humanos (creo que se trata más de psicología que de estética :-).

3. Una expresión que comienza con una negación generalmente es menos legible / comprensible que una expresión que no lo hace.

Entonces, tenemos estos tres requisitos / reglas en competencia, y la verdadera pregunta es: ¿cuáles de ellos son más importantes que otros? Para Allen Holub, la regla n. ° 1 es probablemente la más importante. Para Steve McConnell, es la regla n. ° 2. Pero no creo que realmente pueda elegir solo una de estas reglas como una única línea de referencia.

Apuesto a que ya has adivinado mis prioridades personales aquí (por la forma en que ordené las reglas anteriores :-).

Mis razones son simples:

• La regla n. ° 1 es incondicional e imposible de eludir. Si uno de los bloques es tan largo que se escapa de la pantalla, debe convertirse en el bloque "else". (No, no es una buena idea crear una función / método mecánicamente solo para disminuir el número de líneas en un bloque "if" o "else". Supongo que cada bloque ya tiene una cantidad mínima de líneas lógicamente justificable . )

• La regla n. ° 2 implica muchas condiciones: múltiples construcciones "si-si", todas tienen asimetrías del mismo tipo, etc. Por lo tanto, no se aplica en muchos casos.

  Además, a menudo observo el siguiente fenómeno interesante: cuando se aplica la regla n. ° 2 y cuando se usa correctamente, ¡en realidad no entra en conflicto con la regla n. ° 1! Por ejemplo, cada vez que tengo un montón de afirmaciones "if-else" con asimetría "normal vs. anormal", todas las rutas "anormales" son más cortas que las "normales" (o viceversa). No puedo explicar este fenómeno, pero creo que es solo un signo de buena organización del código. En otras palabras, cada vez que veo una situación en la que las reglas n. ° 1 y n. ° 2 entran en conflicto, empiezo a buscar "olores de código" y la mayoría de las veces encuentro algunas; y después de refactorizar - tada! no más dolorosa elección entre la regla n. ° 1 y la regla n. ° 2 :-)

• Finalmente, la regla n. ° 3 tiene el alcance más pequeño y, por lo tanto, es la menos crítica.

  Además, como mencionan aquí otros colegas, a menudo es muy fácil "engañar" con esta regla (por ejemplo, escribir "if (disabled)", en lugar de "if (! Enabled) ...").

Espero que alguien pueda darle sentido a esta obra ...

Answer 21

En general, pongo el resultado positivo (por lo tanto, el método) al comienzo, así que:

if(condition)
{
doSomething();
}
else
{
System.out.println("condition not true")
}

Pero si la condición tiene que ser falsa para que se use el método, yo haría esto:

if(!condition)
{
doSomething();
}
else
{
System.out.println("condition true");
}

Answer 22

Si debe tener múltiples puntos de salida, colóquelos primero y aclárelos:

if TerminatingCondition1 then
Exit
if TerminatingCondition2 then
Exit

Ahora podemos progresar con lo habitual:

if NormalThing then
DoNormalThing
else
DoAbnormalThing

Answer 23

Si una de las dos rutas es muy corta (de 1 a 10 líneas más o menos) y la otra es mucho más larga, sigo la regla de Holub que se menciona aquí y coloco la parte más corta del código en if. Eso hace que sea más fácil ver el flujo if / else en una pantalla cuando se revisa el código.

Si eso no es posible, entonces me estructure para que la condición sea lo más simple posible.