¿O nos estamos pegando a nuestra enseñanza "& &, ||,!" ¿camino?¿Alguien está usando los operadores booleanos nombrados?
¿Alguna idea de por qué deberíamos usar una u otra?
Me pregunto porque varias respuestas indican que el código debe ser lo más natural posible, pero no he visto mucho código con "y, o no", aunque esto es más natural.
Esos no eran compatibles en los viejos tiempos. E incluso ahora necesita dar un cambio especial a algunos compiladores para habilitar estas palabras clave. Eso es probablemente porque la base de código anterior puede haber tenido algunas funciones || variables llamadas "y" "o" "no".
Es curioso, acabo de quemarme ... Estaba compilando un viejo código de C++ que estaba escrito claramente antes de que los operadores booleanos nombrados fueran compatibles (John Lakos, Te estoy mirando) y había variables y rutinas con el nombre "o" ... avance rápido hasta hoy, barras de compilación, el código debe cambiar ... – Dan
Me gusta la idea del operador not porque es más visible que el operador !. Por ejemplo:
if (!foo.bar()) { ... }
if (not foo.bar()) { ... }
Sugiero que el segundo sea más visible y legible. Sin embargo, no creo que el mismo argumento se aplique necesariamente a los formularios and y or.
Sí, estoy de acuerdo con esto. Voy más allá y creo una función Not(), porque no solo tengo problemas para ver la criatura, también tengo problemas para recordar su precedencia. –
La función es un poco exagerada. Use paréntesis en su lugar! – inazaruk
Punto válido. Aunque la iluminación de sintaxis viene al rescate, no tenemos que confiar en eso. –
"¿Qué hay en un nombre? Lo que llamamos & &, || o! Por cualquier otro nombre podría oler tan dulce."
En otras palabras, natural depende de lo que está acostumbrado.
Estoy de acuerdo y ¡qué más soy! convencido de que el programador promedio codificará más rápido usando 'y' | 'no'. – ilivewithian
y aquellos de nosotros que hemos usado && y || durante veinte años más o menos será lento para cambiar de ella. –
y aquellos de nosotros que hemos usado || y && durante 30 años más o menos, pero que también codifica mucho en python, estará obligado a escribir un día 'if (x <3 y y <7)' sin siquiera pensar en ello, y luego sorprenderse cuando un co- el trabajador que lo compila con MSVC comete una 'corrección' para cambiarlo a &&. Así es como descubrí que 'y' era posible ... – greggo
Me gusta la idea, pero no la use. Estoy tan acostumbrado a la forma antigua que no me proporciona ninguna ventaja de ninguna manera. Lo mismo es cierto para el resto de nuestro grupo, sin embargo, me preocupa que podamos cambiar para ayudar a evitar que los futuros programadores tropiecen con los viejos símbolos.
Personalmente me gusta que los operadores se vean como operadores. Es todo matemática, y a menos que comiences a usar operadores "agregar" y "restar" también comienza a parecer un poco inconsistente.
Creo que algunos idiomas se adaptan al estilo de la palabra y algunos se ajustan a los símbolos, ya sea porque es a lo que la gente está acostumbrada y funciona. Si no está roto, no lo arregles.
También existe la cuestión de la precedencia, que parece ser una de las razones para presentar a los nuevos operadores, pero ¿quién puede molestarse en aprender más reglas de las que necesitan?
Aunque he estado programando C++ desde hace bastante tiempo, no sabía que las palabras clave "y" "o" y "no" estaban permitidas, y nunca las he visto usar.
Busqué en mi libro de C++, y encontré una pequeña sección que menciona una representación alternativa para los operadores normales "& &", "||" y "!", donde explica que están disponibles para personas con teclados no estándar que no tienen el "&! |" símbolos.
Un poco como trigrafos en C.
Básicamente, se confundiría por su uso, y creo que no sería el único. El uso de una representación que no es estándar, realmente debería tener una buena razón para ser utilizado. Y si se usa, debe usarse de manera consistente en el código y describirse en el estándar de codificación.
En los casos en que programa con nombres directamente correlacionados con el mundo real, que tienden a utilizar 'y' y 'o', por ejemplo:
if(isMale or isBoy and age < 40){}
Entonces, para resumir: no se utiliza mucho porque de la siguiente combinación
Gracias por sus pensamientos
Los operadores dígrafo y trigraph fueron diseñados en realidad más para los sistemas que no portaban el juego de caracteres ASCII estándar - como unidades centrales de IBM (que utilizan EBCDIC). En los viejos tiempos de las impresoras mecánicas, había una cosa llamada "cadena de impresión de 48 caracteres" que, como su nombre implicaba, solo tenía 48 caracteres. A-Z (mayúscula), 0-9 y un puñado de símbolos. Como uno de los símbolos faltantes era un guión bajo (que se representaba como un espacio), esto podría hacer que trabajar con lenguajes como C y PL/1 fuera una actividad realmente divertida (¿son 2 palabras o una palabra con guion bajo ???).
Convencional C/C++ está codificado con los símbolos y no con los dígrafos. Aunque se sabe que # definí "NO", ya que hace que el significado de una expresión booleana sea más obvio, y es visualmente más difícil de ignorar que un pequeño y flaco "!".
La tecnología de impresión informa el estilo. Solía hacer un diseño esquemático con salida a un trazador de plumillas, y era un estilo obligatorio colocar puntos en los empalmes en "T" - no era necesario para obtener la lista de conexiones correcta, pero si se saltaba un lápiz y no lo hacía tener un punto, la intersección no estaría clara en el papel. Más tarde, con impresoras láser, los puntos no fueron necesarios. – greggo
Es bueno usarlos en Eclipse + gcc, ya que están resaltados. Pero entonces, el código no compila con algunos compiladores :-(
Ojalá pudiera usar || y & & en el habla normal. Las personas intentan muy mal entender cuando digo "y" o "o". ..
Uno de los problemas con su uso (al menos para mí) es que en MSVC tiene que incluir iso646.h o utilizar el (en su mayoría inservibles) interruptor/Za.
el principal problema que tengo con ellos es la captura -22 que no son de uso común, por lo que requieren que mi cerebro procese activamente el significado, donde los operadores pasados de moda están más o menos arraigados (algo así como la diferencia entre leer una lección aprendida idioma vs. tu lengua materna).
Aunque estoy seguro de que superaría ese problema si su uso se hiciera más universal. Si eso ocurriera, entonces tendría el problema de que algunos operadores booleanos tienen palabras clave, mientras que otros no lo hacen, por lo que si se utilizan palabras clave alternativas, es posible que vea expresiones como:
if ((x not_eq y) and (y == z) or (z <= something)) {...}
cuando me parece que deberían tienen fichas alternativos para todos los (al menos comparación) operadores:
if ((x not_eq y) and (y eq z) or (z lt_eq something)) {...}
Esto es porque la razón se proporcionaron las palabras clave alternativas (y dígrafos y trigrafos) no era hacer las expresiones más legible - que era porque históricamente han sido (y tal vez todavía lo son) teclados y/o páginas de códigos en algunas localidades que no tienen cierta puntuación ch personajes. Por ejemplo, a la parte invariable de la página de códigos ISO 646 (sorpresa) le faltan los caracteres '|', '^' y '~', entre otros.
Y para ampliar ligeramente la pregunta, ¿alguien está usando dígrafos? –
Ni siquiera sabía que existían. Los he probado ahora y no compilan. –
Probablemente necesite buscar una opción en su compilador para activarla. – inazaruk