2010-04-30 10 views
10

Estaba leyendo algo de código C# mío hoy y encontré esta línea:¿Te gustan los idiomas que te permiten poner el "entonces" antes del "si"?

if (ProgenyList.ItemContainerGenerator.Status != System.Windows.Controls.Primitives.GeneratorStatus.ContainersGenerated) return; 

en cuenta que se puede decir sin necesidad de desplazarse de que se trata de un "if" que trabaja con ItemContainerGenerator.Status, pero no se puede Dígale fácilmente que si la cláusula "si" se evalúa como "verdadera", el método regresará en ese punto.

Realísticamente debería haber movido la declaración de "retorno" a una línea por sí mismo, pero me hizo pensar en los idiomas que permiten primero la parte "entonces" de la declaración. Si C# permitía, la línea podría tener este aspecto:

return if (ProgenyList.ItemContainerGenerator.Status != System.Windows.Controls.Primitives.GeneratorStatus.ContainersGenerated); 

Esto podría ser un poco "argumentativo", pero me pregunto lo que la gente piensa acerca de este tipo de construcción. Podría servir para que las líneas como la de arriba sean más legibles, pero también podría ser desastroso. Imagínese este código:

return 3 if (x > y); 

Lógicamente, sólo puede volver si x> y, porque no hay "otra cosa", pero parte de mí mira eso y piensa, "seguimos regresando si x < = y si? Entonces, ¿qué estamos volviendo?

¿Qué opina del constructo "entonces antes del si"? ¿Existe en tu idioma de elección? ¿Lo usas a menudo? ¿C# se beneficiaría de esto?

+5

¿Qué hay de 'x = 3 si (a = b)' –

+1

Interesante, pero más a menudo que el 'si' desencadena un bloque de código, no es una operación simple. – UpTheCreek

+2

Sí, tal vez solo tiene sentido en declaraciones de devolución donde es un poco menos ambiguo. ¡Responda con una respuesta completa si lo desea, @codeka! Es CW así que no es para rep. –

Respuesta

4

Es feo para mí. La sintaxis existente mucho mejor.

if (x > y) return 3; 
+0

Solo se ve feo porque no estás acostumbrado. Lo mismo cuando se aprende un nuevo idioma. Al principio, la gramática es extraña, desconcertante y sencillamente incorrecta. Sin embargo, te acostumbras y empiezas a pensar en ese idioma y tiene más sentido ... El japonés es un buen ejemplo: "Mañana un auto rojo con techo corredizo quiere comprar", es una oración transliterada. El verbo es siempre (más o menos) lo último que dices. Lo que significa que estableces las partes de la frase al principio, el sujeto, el objeto y luego las unes al final. Simplemente es diferente, eso es todo. Igual que este código – Armstrongest

+1

Derecha. pero las cosas en cualquier idioma están en una sola forma, para evitar confusiones. y si permitimos escribir la misma declaración tanto desde el final al principio como desde el principio hasta el final, esto será muy confuso, porque usted lee algo pero no lo sabe de inmediato, si este es el comienzo o el final. –

+0

es igualmente correcta, y no confuso, en Inglés decir "voy a comprar el coche rojo si tengo suficiente dinero" vs "Si tengo suficiente dinero voy a comprar el coche rojo". Darle al programador la opción le permite poner más énfasis en lo que es importante. –

9

Sí. Se lee mejor. Ruby tiene esto como parte de su sintaxis - el término siendo 'statement modifiers'

irb(main):001:0> puts "Yay Ruby!" if 2 == 2 
Yay Ruby! 
=> nil 
irb(main):002:0> puts "Yay Ruby!" if 2 == 3 
=> nil 

Para cerrar, necesito hacer hincapié en que es necesario 'utilizar esto con discreción'. La expresión de rubí es usar esto para frases simples. Se puede abusar, sin embargo, supongo que esto entra en el ámbito del desarrollo responsable, no se restrinja a los mejores desarrolladores mediante la construcción de restricciones para proteger a los pobres.

10

No me gusta la ambigüedad que esto invita. Considere el siguiente código:

doSomething(x) 
if (x > y); 
doSomethingElse(y); 

¿Qué está haciendo? Sí, el compilador podría resolverlo, pero parecería bastante confuso para un programador.

+3

Ese es un gran ejemplo de la ambigüedad que esto podría presentar. ¿Tal vez si se limitara a declaraciones de "devolución"? No se. –

+0

¿Dónde está la ambigüedad? Todo lo que has hecho es insertar una nueva línea. – liammclennan

+0

No veo la ambigüedad. Está perfectamente claro cómo se analizaría esto. – Blindy

1

Creo que Larry Wall fue muy inteligente cuando puso esta función en Perl. La idea es que quieras poner la parte más importante al principio donde sea fácil de ver. Si tiene una declaración breve (es decir, no una declaración compuesta), puede ponerla antes del if/while/etc. Si tiene una declaración larga (es decir, compuesta), va entre llaves después de la condición.

0

Tanto Perl como Ruby tienen esto y funciona bien. Personalmente, estoy bien con tanta funcionalidad que quieres arrojarme. Cuantas más opciones tenga para escribir mi código, mejor será la calidad general, ¿verdad? "La herramienta adecuada para el trabajo" y todo eso.

Aunque es realista, es un punto discutible ya que es bastante tarde para una adición tan fundamental en el ciclo de vida de C#.Estamos en el punto donde cualquier cambio de sintaxis menor requeriría mucho trabajo para implementar debido al tamaño del código del compilador y su algoritmo de análisis de sintaxis. Para que se considere una nueva adición, tendrá que aportar bastante funcionalidad, y esta es solo una forma (no tan) diferente de decir lo mismo.

3

no veo ningún problema con

return 3 if (x > y); 

Probablemente le molesta, ya que no está acostumbrado a la sintaxis. También es bueno poder decir

return 3 unless y <= x 

Esta es una buena opción de sintaxis, pero no creo que C# lo necesite. reformatear

+0

Sí, Ruby permite la palabra clave a menos. 'devolver 'el éxito!' a menos que errorCount> 0' en vez de 'return 'success' si errorCount <1' Se podría argumentar que la primera afirmación es más clara. – Armstrongest

15

Vamos que un poco y ver:

using System.Windows.Controls.Primitives; 

... 

if (ProgenyList.ItemContainerGenerator.Status != GeneratorStatus.ContainersGenerated) 
{ 
    return; 
} 

Ahora lo difícil que es para ver la instrucción de retorno? Es cierto que en SO aún necesita desplazarse para ver la totalidad de la condición, pero en un IDE no tendría que ... en parte debido a que no trató de poner la condición y el resultado en la misma línea, y debe cumplir con la fiesta a la directiva using.

El beneficio de la sintaxis C# existente es que el orden textual refleja el orden de ejecución. Si desea saber qué sucederá, lea el código de arriba a abajo.

Personalmente no soy partidario de "devolver si ..." - prefiero reformatear el código para facilitar la lectura que cambiar el orden.

+1

Bueno, con métodos anónimos y expresiones lamdba, el orden textual no refleja necesariamente el orden de ejecución. –

+0

@Senthil: cierto, pero creo que en ese caso los beneficios superan los costos. En esta situación, realmente no creo que ese sea el caso. –

+0

No me gusta que se necesiten cuatro líneas de código para expresar un concepto tan simple. –

4

Creo que probablemente sea correcto si el alcance estuviera limitado a solo return declaraciones. Como dije en mi comentario, imagina si esta fueron permitidos:

{ 
    doSomething(); 
    doSomethingElse(); 

    // 50 lines... 

    lastThink(); 
} if (a < b); 

Pero incluso sólo permitiendo que sólo en return declaraciones es probablemente una pendiente resbaladiza. La gente preguntará, "return x if (a); está permitido, ¿por qué no algo así como doSomething() if (a);?" y luego estás en tu camino por la ladera :)

Sé que otros idiomas se salgan con la suya, pero la filosofía de C# es más acerca de hacer The One Right Way TM fácil y tener más de una manera de hacerlo algo generalmente se evita (aunque con excepciones). Personalmente, creo que funciona bastante bien, porque puedo ver el código de otra persona y saber que es más o menos del mismo estilo en el que lo escribiría.

+0

'doSomething() if (a);' está perfectamente bien. Sin embargo, su ejemplo ... probablemente no pudo ser implementado. Solo se limitaría a expresiones de declaración individuales. – Blindy

+3

C# no intenta "de una manera correcta". Puedo pensar en al menos 4 formas diferentes de hacer condicionales en C#, 2 sintaxis LINQ completamente diferentes, 4 formas diferentes de iterar, etc. ¿De qué está hablando esta pendiente resbaladiza? – liammclennan

+1

parece una expresión 'do/while'. –

-1

Se considera incorrecto gramaticalmente poner la respuesta antes que la pregunta , ¿por qué sería diferente en el código?

+1

Correcto, pero esto no está dando la respuesta primero, es poner primero la ACCIÓN. "Comprar huevos si estamos fuera" no es gramaticalmente incorrecto. – Blindy

+1

Dejaré una refutación aquí si te parece bien. :) –

0

Los humanos leen de principio a fin. Al analizar el flujo de código, limits of the short term memory hace que sea más difícil leer las condiciones de postfix debido a un retroceso adicional requerido. Para expresiones cortas, esto puede no ser un problema, pero para expresiones más largas incurrirá en una sobrecarga significativa para usuarios que no son seasoned en el idioma que están leyendo.

+0

Solo lleva tiempo acostumbrarse. Los humanos son notablemente adaptables. Mire el tagalo ... 'Na kay Tatay ang susi' transliterado es' At with Father the keys' traducido es '" El padre tiene las llaves ".' Estoy seguro de que los hablantes de tagalo se sentirían como en casa con 'return x if ' – Armstrongest

1

Personalmente me gustan los idiomas que me permiten elegir.

Dicho esto, si refactoriza, así como el formato, es probable que no importa qué estilo que utiliza, porque van a ser igualmente legibles:

using System.Windows.Controls.Primitives; 

... 
var isContainersGenerated = 
    ProgenyList.ItemContainerGenerator.Status == GeneratorStatus.ContainersGenerated; 

if (!isContainersGenerated) return; 
//alternatively 

return if (!isContainersGenerated); 
1

mostró de acuerdo con confuso, nunca oído hablar de esta construcción antes, así que creo que forma correcta, utilizando entonces antes si debe ser siempre el resultado de contenidos cosa, como

return (x > y) ? 3 : null; 

camino a otro no hay ningún punto de utilizar construcciones imperativas como

return 3 if (x > y); 
return 4 if (x = y); 
return 5 if (x < y); 

en mi humilde opinión es un poco raro, porque no tengo ni idea de dónde usarlo ...

1

Existe la preocupación de la lectura del código que cree una declaración se ejecutar sólo más tarde para descubrir que la fuerza ejecutar.

Por ejemplo, si lees "doSomething (x)", estás pensando "bien, entonces esto llama doSomething (x)" pero luego lees el "si" y tienes que darte cuenta de que la llamada anterior es condicional en la declaración if.

Cuando aparece el "si" primero, usted sabe de inmediato que el siguiente código podría ocurrir y puede tratarlo como tal.

Tendemos a leer secuencialmente, por lo que leer y pensar "lo siguiente puede pasar" es mucho más fácil que leer y luego darse cuenta de que todo lo que acaba de leer necesita ser reparado y que debe evaluar todo para ver si está dentro del alcance de su nueva declaración if.

0

Es como un montón de cosas realmente, tiene mucho sentido cuando lo usa en un contexto limitado (un trazador de líneas), y no tiene ningún sentido si lo usa en cualquier otro lugar.

El problema con eso, por supuesto, es que sería casi imposible restringir el uso a donde tiene sentido, y permitir su uso donde no tiene sentido es simplemente extraño.

Sé que hay un movimiento que surge de los lenguajes de scripting para tratar de minimizar el número de líneas de código, pero cuando se habla de un lenguaje compilado, la legibilidad es realmente la clave y por mucho que pueda ofender sentido del estilo, el modelo de 4 líneas es más claro que el inverso si.

0

Creo que es una construcción útil y un programador la usaría para enfatizar lo que es importante en el código y para quitar importancia a lo que no es importante. Se trata de escribir un código revelador de intenciones.

utilizo algo como esto (en CoffeeScript):

index = bla.find 'a'
retorno si el índice es -1

Lo más importante en este código se a salir (regresar) si no se encuentra nada - observe las palabras que acabo de explicar que la intención estaba en el mismo orden que en el código.

Así que este constructo me ayuda a código de una manera que refleja mi intención ligeramente mejor.

No debería ser demasiado sorprendente darse cuenta de que el orden en que corrige Inglés o tradicional gramática del lenguaje de programación generalmente ha requerido, no siempre es la forma más eficaz o más simple de crear significado.

A veces es necesario dejar que todo el rato y verdaderamente reevaluar lo que es realmente la mejor manera de hacer algo.

Cuestiones relacionadas