c++ - igual - js different operator
¿Cómo verificar para los iguales?(0== i) o(i== 0) (28)
De acuerdo, sabemos que las siguientes dos líneas son equivalentes:
(0 == i)-
(i == 0)
Además, el primer método se fomentó en el pasado porque eso le hubiera permitido al compilador dar un mensaje de error si accidentalmente usó ''='' en lugar de ''==''.
Mi pregunta es: ¿en la generación actual de IDE y de compiladores inteligentes bastante hábiles, todavía recomiendan el primer método?
En particular, esta pregunta me vino a la mente cuando vi el siguiente código:
if(DialogResult.OK == MessageBox.Show("Message")) ...
En mi opinión, nunca recomendaría lo anterior. Cualquier segunda opinión?
Tercera opción: no permitir la asignación dentro de los condicionales por completo:
En situaciones de alta confiabilidad, no está permitido (sin una buena explicación en los comentarios anteriores) asignar una variable en un enunciado condicional: elimina por completo esta pregunta porque la apagas en el compilador o con LINT y solo en situaciones muy controladas. ¿puedes usarlo?
Tenga en cuenta que, en general, se genera el mismo código ya sea que la asignación se realice dentro del condicional o fuera de él; es simplemente un atajo para reducir la cantidad de líneas de código. Siempre hay excepciones a la regla, pero nunca tiene que estar en el condicional; siempre puedes escribir la salida si es necesario.
Entonces, otra opción es simplemente no permitir tales declaraciones, y cuando sea necesario, use los comentarios para desactivar la comprobación de LINT para este error común.
-Adán
- (0 == i)
Siempre elegiré este. Es cierto que la mayoría de los compiladores de hoy no permiten la asignación de una variable en un enunciado condicional, pero la verdad es que algunos lo hacen. En la programación para la web de hoy, tengo que usar una gran cantidad de lenguajes en un sistema. Al usar 0 == i, siempre sé que la declaración condicional será correcta, y no estoy confiando en que el compilador / intérprete capte mi error por mí. Ahora bien, si tengo que pasar de C # a C ++ o JavaScript, sé que no voy a tener que rastrear los errores de asignación en las declaraciones condicionales de mi código. Para algo tan pequeño y para que ahorre esa cantidad de tiempo, es pan comido.
Bueno, depende del lenguaje y el compilador en cuestión. El contexto es todo.
En Java y C #, el error tipo "asignación en lugar de comparación" termina con un código no válido, aparte de la muy rara situación en la que se comparan dos valores booleanos.
Puedo entender por qué uno querría usar el formulario "seguro" en C / C ++, pero, francamente, la mayoría de los compiladores de C / C ++ le advertirán si realiza el error tipográfico de todos modos. Si está utilizando un compilador que no funciona, debe preguntarse por qué :)
La segunda forma (variable, a continuación, constante) es más legible en mi opinión, por lo que en cualquier lugar que definitivamente no va a causar un problema, lo uso.
Creo que el único factor que alguna vez fuerza a uno sobre el otro es si la cadena de herramientas no proporciona advertencias para capturar asignaciones en expresiones. Mi preferencia como desarrollador es irrelevante. Una expresión es mejor servida al presentar claramente la lógica comercial. Si (0 == i) es más adecuado que (i == 0) lo elegiré. Si no, elegiré el otro.
Muchas constantes en expresiones están representadas por nombres simbólicos. Algunas guías de estilo también limitan las partes del discurso que se pueden usar para los identificadores. Los uso como una guía para ayudar a dar forma a cómo se lee la expresión. Si la expresión resultante se lee libremente como pseudo código, generalmente estoy satisfecho. Simplemente dejo que la expresión se exprese y, si me equivoco, generalmente quedará atrapada en una revisión por pares.
Creo que es solo una cuestión de estilo. Y ayuda con el uso accidental del operador de asignación.
Sin embargo, no le pediría al programador que creciera.
Diría que (i == 0) sonaría más natural si intentas pronunciar una línea en inglés simple (y ambiguo). Sin embargo, realmente depende del estilo de programación del programador o de los estándares a los que deben adherirse.
En C, sí, pero ya debería haber activado todas las advertencias y estar compilando sin advertencia, y muchos compiladores C lo ayudarán a evitar el problema.
Raramente veo mucho beneficio de un punto de vista de legibilidad.
En realidad, el ejemplo de DialogResult es un lugar donde recomendaría ese estilo. Coloca la parte importante de if () hacia la izquierda donde se puede ver. Si está a la derecha y el cuadro de mensajes tiene más parámetros (lo cual es probable), es posible que tenga que desplazarse hacia la derecha para verlo.
OTOH, nunca vi mucho uso en el estilo "(0 == i)". Si recuerdas poner la constante primero, puedes recordar usar dos signos iguales,
Esta es una de mis mayores preocupaciones. No hay ninguna razón para disminuir la legibilidad del código (si (0 == i), ¿cómo ?, ¿cómo puede cambiar el valor de 0?) Para capturar algo que cualquier compilador de C escrito en los últimos veinte años puede capturar automáticamente.
Sí, lo sé, la mayoría de los compiladores C y C ++ no lo activan de manera predeterminada. Busque el interruptor adecuado para encenderlo. No hay excusa para no conocer tus herramientas.
Realmente me pone de los nervios cuando veo que se arrastra a otros idiomas (C #, Python) que normalmente lo marcaría de todos modos!
Estoy intentando usar siempre el primer caso (0 == i), ¡y esto me salvó la vida varias veces!
La legibilidad del código es una de las cosas más importantes para el código de más de unos cientos de líneas, y definitivamente i == 0 es mucho más fácil que el reverso
La regla 0 para todos los estándares de codificación debe ser "escribir código que otro humano pueda leer fácilmente". Por esa razón, voy con (valor que cambia más rápidamente) test-against (menos-cambio rápido de valor, o constante), es decir, "i == 0" en este caso.
Incluso cuando esta técnica es útil, la regla debería ser "evitar poner un lvalue a la izquierda de la comparación", en lugar de "poner siempre una constante a la izquierda", que es como suele interpretarse, por ejemplo, no hay nada ser ganado por escrito
if (DateClass.SATURDAY == dateObject.getDayOfWeek())
si getDayOfWeek () devuelve una constante (¡y por lo tanto no es un valor l) de todos modos!
Tengo suerte (a este respecto, al menos) de que actualmente estoy codificando principalmente en Java y, como se ha mencionado, if (someInt = 0) no compilará.
La advertencia sobre la comparación de dos booleanos es un poco descabellada, ya que la mayoría de las veces se comparan dos variables booleanas (en cuyo caso el intercambio de ellas no ayuda) o se prueba si se establece una bandera, y ay ¡Apuesto a ti si te veo comparando algo explícitamente con verdadero o falso en tus condicionales! Grrrr!
Mi empresa acaba de dejar el requisito de hacer si (0 == i) de sus estándares de codificación. Puedo ver que tiene mucho sentido, pero en la práctica parece estar al revés. Es una lástima que, por defecto, un compilador de C probablemente no te avise si (i = 0).
No importa en C # si pones la variable primero o último, porque las asignaciones no se evalúan como bool (o algo que se puede convertir en bool), por lo que el compilador detecta errores como "if (i = 0) EntireCompanyData.Delete ( ) "
Entonces, en el mundo de C # al menos, es una cuestión de estilo más que de desesperación. Y poner la variable al final no es natural para los hablantes de inglés. Por lo tanto, para un código más legible, variable primero.
Personalmente, no me gusta (1) y siempre lo hago (2), sin embargo eso se invierte para poder leer cuadros de diálogo y otros métodos que pueden ser muy largos. No se ve mal cómo no es, pero si expandes el MessageBox a su longitud completa. Tienes que desplazarte completamente hacia la derecha para descubrir qué tipo de resultado estás devolviendo.
Así que, aunque estoy de acuerdo con sus afirmaciones de la comparación simplista de los tipos de valores, no creo necesariamente que deba ser la regla para cosas como cuadros de mensaje.
Podríamos seguir y seguir sobre lo buenos que han sido nuestros IDEs, pero todavía estoy sorprendido por la cantidad de personas que bajan los niveles de advertencia en su IDE.
Por lo tanto, para mí, siempre es mejor pedirle a la gente que use (0 == i), como nunca se sabe, qué programador está haciendo qué. Es mejor estar "seguro que arrepentido"
Prefiero (i == 0), pero aún así hago una "regla" para mí (0 == i), y luego la rompo cada vez.
"¿Eh?", Piensas.
Bien, si estoy tomando la decisión consciente de poner un valor l a la izquierda, entonces presto suficiente atención a lo que estoy escribiendo para notar si escribo "=" para "==". Espero. En C / C ++ generalmente uso -Wall para mi propio código, que genera una advertencia en gcc para la mayoría de los errores "=" para "==" de todos modos. No recuerdo haber visto esa advertencia recientemente, tal vez porque cuanto más programo, más reflexivo paranoico soy acerca de los errores que he cometido antes ...
if(DialogResult.OK == MessageBox.Show("Message"))
me parece equivocado El objetivo del truco es evitar asignar accidentalmente algo.
Pero, ¿quién va a decir si DialogResult.OK es más o menos probable que evalúe a un tipo asignable que MessageBox.Show ("Message")? En Java, una llamada a un método no puede ser asignable, mientras que un campo puede no ser final. Entonces, si le preocupa escribir typing = for ==, debería ser al revés en Java para este ejemplo. En C ++ tampoco, ninguno o ambos podrían ser asignables.
(0 == i) solo es útil porque sabes con absoluta certeza que un literal numérico nunca es asignable, mientras que yo podría serlo.
Cuando ambos lados de su comparación son asignables, no puede protegerse de una asignación accidental de esta manera, y eso sucede cuando no sabe cuál es asignable sin buscarlo. No hay ningún truco de magia que diga "si los pones de forma contraintuitiva, estarás a salvo". Aunque supongo que atrae la atención sobre el tema, de la misma manera que mi regla de "siempre romper la regla".
Prefiero el segundo, (i == 0), porque se siente mucho más natural al leerlo. Le preguntas a la gente: "¿Tienes 21 años o más?", No "¿Tiene 21 años o menos que tu edad?"
Quizás no sea una respuesta a tu pregunta. Intento utilizar === (comprobando que sean idénticos) en lugar de igualdad. De esta forma, no se realiza ninguna conversión de tipo y obliga al programador a asegurarse de que se pase el tipo correcto.
Si tiene una lista de if que no puede representarse bien mediante un modificador (debido a una limitación de idioma, tal vez), entonces prefiero ver:
if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }
porque le permite ver rápidamente cuáles son los valores importantes que necesita verificar.
En particular, en Java me parece útil hacer:
if ("SomeValue".equals(someString)) {
}
porque someString puede ser nulo, y de esta manera nunca obtendrás una NullPointerException. Lo mismo aplica si está comparando constantes que sabe que nunca serán nulas contra objetos que pueden ser nulos.
Siempre voy con el segundo método. En C #, escribir
if (i = 0) {
}
resulta en un error de compilación (no se puede convertir int a bool) de todos modos, por lo que podría cometer un error no es realmente un problema. Si prueba un bool, el compilador sigue emitiendo una advertencia y no debería comparar un bool con verdadero o falso. Ahora sabes por qué.
Solía estar convencido de que la opción más legible (i == 0) era la mejor manera de hacerlo.
Luego tuvimos una falla en la producción (afortunadamente no la mía), donde el problema era un error tipo ($ var = SOME_CONSTANT). Los clientes comenzaron a recibir correos electrónicos destinados a otros clientes. Datos de tipo sensible también.
Puedes argumentar que Q / A debería haberlo atrapado, pero no lo hicieron, esa es una historia diferente.
Desde ese día, siempre he presionado para la versión (0 == i). Básicamente elimina el problema. Se siente antinatural, así que prestas atención, para que no cometas el error. Simplemente no hay forma de equivocarse aquí.
También es mucho más fácil detectar que alguien no invirtió la declaración if en una revisión del código que el hecho de que alguien haya asignado accidentalmente un valor en un if. Si el formato es parte de los estándares de codificación, las personas lo buscan. Normalmente, las personas no depuran el código durante las revisiones del código, y el ojo parece escanear más de un (i = 0) frente a un (i == 0).
También soy un admirador mucho más grande del Java "Constant String" .equals (dynamicString), sin excepciones de puntero nulo es algo bueno.
Tiene razón en que ubicar el componente importante primero ayuda a la legibilidad, ya que los lectores tienden a navegar principalmente por la columna de la izquierda, y colocar allí información importante ayuda a garantizar que se note.
Sin embargo, nunca le hable a un compañero de trabajo, e insinuar que esa sería su acción, incluso en broma, no le dará altas calificaciones aquí.
Uso (i == 0) por la sencilla razón de que se lee mejor. Hace un flujo muy suave en mi cabeza. Cuando lees el código a ti mismo para depuración u otros fines, simplemente fluye como leer un libro y tiene más sentido.
Ya sabes, siempre uso el formato if (i == 0) del condicional y mi razón para hacer esto es que escribo la mayor parte de mi código en C # (que marcaría el otro de todos modos) y hago una prueba primero enfoque de mi desarrollo y mis pruebas generalmente detectarían este error de todos modos.
He trabajado en tiendas donde intentaron aplicar el formato 0 == i, pero me resultó incómodo escribir, incómodo de recordar y simplemente terminó siendo un tema de consumo para los revisores de códigos que buscaban frutas fáciles de encontrar.
Yo personalmente prefiero el uso del formato de valor de operando variable en parte porque lo he estado usando tanto tiempo que se siente "natural" y en parte porque parece ser la convención predominante. Hay algunos idiomas que hacen uso de sentencias de asignación como las siguientes:
:1 -> x
Entonces, en el contexto de esos idiomas puede ser bastante confuso ver lo siguiente incluso si es válido:
:if(1=x)
Entonces eso es algo a considerar también. Estoy de acuerdo con que la respuesta del cuadro de mensaje sea un escenario en el que usar un formato de variable de valor de operación funciona mejor desde un punto de vista de legibilidad, pero si busca constancia, entonces debe renunciar a su uso.
ambos son iguales, aunque preferiría ligeramente la variante 0 == i.
cuando se comparan cadenas, es más propenso a errores comparar "MyString" .equals (getDynamicString ())
ya que, getDynamicString () puede devolver nulo. para ser más consciente, escriba 0 == i
if(DialogResult.OK == MessageBox.Show("Message")) ...
Siempre recomendaría escribir la comparación de esta manera. Si el resultado de MessageBox.Show ("Message") puede ser nulo, se arriesga a una NPE / NRE si la comparación es al revés.
Las operaciones matemáticas y lógicas no son reflexivas en un mundo que incluye NULLs.