2012-04-09 10 views
8

En una C++ coding style guide, encontré una recomendación en particular (página 41, la recomendación número 53):C++ styleguide: ¿por qué tener valores no-l en el lado izquierdo?

Siempre tienen los no lvalues ​​en el lado izquierdo (en lugar de 0 == ii == 0).

¿Y no entiendo para qué sirve esto? ¿Debes apegarte a esta práctica?

No soy y no sé por qué es una buena práctica. La única ventaja que se me ocurre es que evitará confundir una tarea involuntaria con una comparación (if (foo = 0){} versus if (foo == 0){})

¿Tiene alguna otra idea de por qué debería usarla?

+0

Yo no uso eso. Han pasado muchos años desde que cometí el error = /==. La experiencia y la habilidad han sido una mejor contramedida para mí que las expresiones incómodas como Yoda Condition. Su decisión de usar o no utilizar debe basarse en si le gusta, si le parece que lo ayuda y si el estándar de codificación de su proyecto lo prohíbe o lo requiere. –

+2

La ventaja de '(0 == i)' es que puede detectar algunos errores '=' contra '=='. La desventaja es que leerlo hace sangrar mis ojos. –

Respuesta

14

Sí, lo adivinaste bien. Es lo bueno, viejo Yoda condition !!!

enter image description here

+2

Most. Increíble. Enlazar. Nunca. Me encantan los "corchetes egipcios" –

+1

+1 para el enlace! –

+0

¡lol! :) Estoy buscando en Google y me gusta esta jerga. Es una lástima que el grupo original de stackoverflow haya sido eliminado. De todos modos, ¿con qué frecuencia se usa la condición Yoda? ¿La mayoría o minoría de programadores lo está usando? – Novellizator

3

Como usted dice, la razón por la que algunas personas lo utilizan de vez en cuando es evitar escribir = cuando quieren decir ==.

Ya que sólo capta algunos casos, cuando se está comparando un lvalue con una constante o rvalue, y cada compilador que conozco le advertirá si haces ese error, hay muy poco sentido hacerlo .

Al menos para hablantes nativos de inglés, hace que el código se lea como si estuviera escrito al revés; entonces una "condición de Yoda" algunos lo llaman hacer. Al igual que muchas reglas en las guías de estilo corporativo, se remonta a una época en que lidiar con compiladores implacables era una prioridad más alta que escribir código legible.

Cuestiones relacionadas