La cuenta tuitera oficial del Windows Dev Center de Microsoft, el sitio web que aúna noticias y recursos para programadores, decidió dar la bienvenida al nuevo año 2022 con un simpático tuit que mostraba el código de un breve programa que se encargaría de felicitarnos el nuevo año desde la consola una vez que el PC que lo ejecuta detectara el cambio de año. ero el tuit adolecía de un problema: que el código era una chapuza, a todos los niveles.
#1:
Es un código pensado para que quede bonito, no para que funcione.
Por cierto, el == sí funciona para cadenas de texto, el problema es que no puedes controlar el juego de caracteres que utilizas y puede funcionar distinto dependiendo de la configuración regional de la máquina donde lo ejecutes.
VsCode, Typescript, C#… gracias Microsoft por todo ese software libre de excelente calidad que me hace ganarme la vida.
#23:
Qué rompehuevos es la gente, es evidente que esa lógica no va a funcionar en ningún lenguaje de programación, ahí faltan cosas. Tan evidente como que eso es una gracia y ya está.
Follamos poquísimo...
#6:
En caso de funcionar, solo funcionaría en el segundo 0:00:00. Si pasase un segundo, no felicitaría el año nuevo aunque ya estuviésemos en él.
Si fuese un programa que se estuviera ejecutando continuamente, solo mostraría ese mensaje durante un segundo y pasado un segundo de las 00:00:00, diría que seguimos en 2021
¿no sería así?
#89:
#18 . Para hablar de Software Libre es siempre mejor saber lo que es, y lo que no es, Software Libre.
Otro tema es que te ganes la vida con eso, aunque con tú trabajo creo que les haces un favor también a ellos (a los de M$), y no tengo nada claro si eso es bueno o malo. (CC #3#82)
#30:
#c-14" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/14">#14 Es que además dice que hay que usar Equals() cuando Equals() sin opciones hace exactamente lo mismo que == pero con el riesgo de comerte un NullReferenceException. Lo dicho en #25, han confundido C# con Java.
#28:
#10 El Excel es un entorno de programación disfrazado de producto de ofimática.
#25:
#c-17" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/17">#17 El artículo no habla de malas prácticas, sino de errores. Dice, literalmente que el operador "==", que sólo es utilizable con operandos (es decir, con números, nunca cadenas de texto ni fechas) . Obviando la gilipollez de que sólo es utilizable con "operandos", ya que por definición un operador se aplica siempre a operandos, se equivoca al decir que sólo es utilizable con números. Es falso, y seguramente viene de confundir cómo se comporta el operador == en C# a cómo lo hace en Java. En Java sí se utiliza == sobre dos cadenas o fechas sólo dará true si ambas contienen la misma referencia de memoria. En C# tanto para cadenas como para fechas, lo que se evalúa es el contenido, por lo que es perfectamente viable utilizar ==.
Por no mencionar que, anidados, suelen provocar un código hadouken:
#4:
Pues si vas a redactar un artículo para corregirle los errores a los demás, cerciórate de no cometerlos tú también:
Pero ahí no acababa la lista de errores del código: la comprobación de igualdad entre ambas fechas se lleva a cabo utilizando el operador "==", que sólo es utilizable con operandos (es decir, con números, nunca cadenas de texto ni fechas) y que devuelve 'true' o 'false', por lo que el código elegido no tiene ningún sentido: lo correcto hubiera sido hacer uso del método 'String.Equals'.
Falso. En C# es perfectamente posible utilizar el operador == para comparar tanto cadenas como fechas, utilizándose los valores para realizar la comparación y no los valores de los punteros como pasa con los tipos referencia. El método Equals() es aconsejable para poder comparar cadenas con ciertas opciones, como por ejemplo ignorando mayúsculas/minúsculas, pero usado sin opciones (y validando que quien lo llame no sea nulo) es lo mismo que ==.
#22:
#17 El tipo dice que no se puede usar con cadenas de texto y si que se puede usar. Eso es un hecho. Otra cosa es que lo uses mal, pero mal puedes usar cualquier cosa.
#34:
#11 he pensado lo mismo. A día de hoy Microsoft está empezando a ser la mejor opción y Windows la mejor plataforma para desarrollar.
Es un código pensado para que quede bonito, no para que funcione.
Por cierto, el == sí funciona para cadenas de texto, el problema es que no puedes controlar el juego de caracteres que utilizas y puede funcionar distinto dependiendo de la configuración regional de la máquina donde lo ejecutes.
#21 Del lenguaje es algo que no van a quitar nunca, porque joderías el código heredado que quisieras compilar con una nueva versión. Más si cabe cuando no es ninguna mala práctica, simplemente el que lo use tiene que ser consciente de qué resultados va a obtener por la definición del lenguaje. No tendría lógica que en una revisión esos resultados cambiaran.
#17 El tipo dice que no se puede usar con cadenas de texto y si que se puede usar. Eso es un hecho. Otra cosa es que lo uses mal, pero mal puedes usar cualquier cosa.
#c-17" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/17">#17 El artículo no habla de malas prácticas, sino de errores. Dice, literalmente que el operador "==", que sólo es utilizable con operandos (es decir, con números, nunca cadenas de texto ni fechas) . Obviando la gilipollez de que sólo es utilizable con "operandos", ya que por definición un operador se aplica siempre a operandos, se equivoca al decir que sólo es utilizable con números. Es falso, y seguramente viene de confundir cómo se comporta el operador == en C# a cómo lo hace en Java. En Java sí se utiliza == sobre dos cadenas o fechas sólo dará true si ambas contienen la misma referencia de memoria. En C# tanto para cadenas como para fechas, lo que se evalúa es el contenido, por lo que es perfectamente viable utilizar ==.
#c-14" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/14">#14 Es que además dice que hay que usar Equals() cuando Equals() sin opciones hace exactamente lo mismo que == pero con el riesgo de comerte un NullReferenceException. Lo dicho en #25, han confundido C# con Java.
#c-47" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/47">#47 Sí, lo digo en #25. Como digo ahí también, creo que viene de confundir C# con Java, aunque en Java también se puede "usar" el operador == con strings y fechas. Lo que pasa es que en Java, salvo con primitivas, siempre se compara el valor de los punteros, mientras que en C# con string y datetime se compara su contenido. Aquí voy a especular porque tendría que mirar lo que voy a decir pero creo que es debido a que C# tiene sobrecarga de operadores y Java no y, por lo tanto, puedes definir cómo se va a comportar el == al implementar cualquier Type.
#c-60" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/60">#60 En cualquier caso, para que el algoritmo funcionase, en lugar de == habría que usar >=, y ahí, con un tipo string, que es el chapuceo más gordo del código ya sí que te vuelves loco. Fundamentalmente porque ya no sabes si estás comparando la longitud de la cadena, la transformación de la cadena en número o la transformación de la cadena en fecha. Y ahí ya tenemos que tener mucha imaginación para pensar que se han pegado un curre increíble sobrecargando ese >=.
Lo suyo era usar la biblioteca de funciones propias del tipo Date de C# y dejarse de conversiones que no pintan nada, aunque su objetivo tiene pinta de haber sido que el código lo entendiera intuitivamente la gente que apenas supiera programar.
#80aunque su objetivo tiene pinta de haber sido que el código lo entendiera intuitivamente la gente que apenas supiera programar
Exacto. El fragmento tiene toda la pinta de estar pensado para que sea código "legible", partiendo de la base que convertir un DateTime a un string para compararlo es absurdo salvo que quieras que uno de los operandos sea "legible" (porque sino habría que inicializar el segundo operando con, por ejemplo, new DateTime(2022, 1, 1), que es menos intuitivo para alguien que no programe. Pero Microsoft se ha encontrado con un gremio bastante puntilloso.
#c-84" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/84">#84 Por eso decimos algunos que para hacerlo realmente útil e igualmente legible con cambiar la comparación de la fecha entera a solamente el año la cosa se habría solucionado (porque, por suerte, en todas las configuraciones regionales el año (gregoriano) se escribe igual):
If (DateTime.Now.Year == 2022) (no soy muy ducho en C# no se si hay que compararlo con un int o un string, pero con comillas o sin ellas, así funciona bien lo que quisieron hacer)
El que no entienda esto tampoco entenderá lo que pusieron originalmente, para qué negarlo.
#84 Al que se le ocurrió utilizar un trozo de código sobre fechas para que fuese intuitivo es que jamás ha trabajado de manera seria con fechas en su vida:
a) O el entorno de programación tiene pocas librerías y funciones y no es ni orientado a objetos y te sale un ladrillo considerable o
b) El sistema es orientado a objetos y tiene bibliotecas en condiciones, pero las llamadas a los métodos de transformación y comparación ya tiran para atrás a cualquier novato.
El lenguaje de los sueños de todo CM:
Si (la_fecha_de_hoy está dentro de 2022) Entonces Escribir "Feliz año nuevo"
SiNo Escribir "Seguimos en 2021"
#1 funcionará con el == pero ya puedes tener puntería.
Y a las 00:01 te dice q viajaste al pasado.
De todas formas, hay q ser Cuñao para pedirle solid a una puta felicitación de año nuevo. El frikerio se nos va de las manos.
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/1">#1 Han cambiado lo de "=="
El articulista lee meneame
Una versión previa de este artículo recogía como erróneo el uso del operador "==" en el contexto del citado código: no es así, C# sí permite usarlo como método de comparación de cadenas de texto.
#1 Dependiendo de la configuración regional, la fecha 5 de enero de 2022 puede ser 05/01/2022 o 01/05/2022 o 2022/01/05 o 01-05-2022 ...
En otras palabras, no es una buena práctica comparar fechas de usando cadenas de texto.
Qué rompehuevos es la gente, es evidente que esa lógica no va a funcionar en ningún lenguaje de programación, ahí faltan cosas. Tan evidente como que eso es una gracia y ya está.
En caso de funcionar, solo funcionaría en el segundo 0:00:00. Si pasase un segundo, no felicitaría el año nuevo aunque ya estuviésemos en él.
Si fuese un programa que se estuviera ejecutando continuamente, solo mostraría ese mensaje durante un segundo y pasado un segundo de las 00:00:00, diría que seguimos en 2021
Pues si vas a redactar un artículo para corregirle los errores a los demás, cerciórate de no cometerlos tú también:
Pero ahí no acababa la lista de errores del código: la comprobación de igualdad entre ambas fechas se lleva a cabo utilizando el operador "==", que sólo es utilizable con operandos (es decir, con números, nunca cadenas de texto ni fechas) y que devuelve 'true' o 'false', por lo que el código elegido no tiene ningún sentido: lo correcto hubiera sido hacer uso del método 'String.Equals'.
Falso. En C# es perfectamente posible utilizar el operador == para comparar tanto cadenas como fechas, utilizándose los valores para realizar la comparación y no los valores de los punteros como pasa con los tipos referencia. El método Equals() es aconsejable para poder comparar cadenas con ciertas opciones, como por ejemplo ignorando mayúsculas/minúsculas, pero usado sin opciones (y validando que quien lo llame no sea nulo) es lo mismo que ==.
#4 Y, dicho sea de paso, un operando no es más que aquello que es objeto de una operación, y puede ser prácticamente cualquier cosa cuando el operador está sobrecargado para que pueda hacer mil cosas diferentes dependiendo del tipo de dato del que sean los operandos. ¿Por qué piensa que un operando únicamente puede ser un número? ¿Nunca estudió lenguajes orientados a objetos? ¿Álgebra?
#c-85" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/85">#85 Si está dentro de un método (y suponiendo que se corrige el problema del "==" cambiándolo por un ">=" o el operador que corresponda en C#, para evitar el error de que se considere estar en 2021 cuando ya es 2022), se me ocurre que se podría añadir un "return" a continuación del mensaje de feliz 2022, para que el método no siga ejecutándose. De esta forma no te haría falta ningún else, el otro mensaje lo pones a continuación sin condición alguna, si ya se ha mostrado el de feliz 2022 el return va a hacer que lo siguiente no se ejecute, y si no cumple la condición de que la fecha ya sea mayor al primer segundo de 2022 entonces es correcto que ejecute lo de 2021.
#85 Puedes poner un return al final del cuerpo del if y dejar el contenido del else fuera. O puedes asignar uno de los mensajes a una variable, cambiarlo dentro de un if cuando se cumpla alguna condición y mostrar finalmente el mensaje después del if.
Esas son sólo dos posibilidades. Estoy seguro de que si me paro a pensarlo las encuentro mejores, como por ejemplo algo que implique el uso de expresiones regulares.
Seguro que todo eso se puede al final reducir a una única línea sencilla.
#59 En este caso sí, es trivial. Pero en código con mucha líneas, si en lugar de usar cláusulas de guarda vas implementando if-else's, cuando llegas a dónde está chicha del código tienes que retener en la mente un montón de condiciones para saber qué se va a ejecutar.
En el código que pone de ejemplo #86, te encontrarías un if al principio del todo y sus consecuencias (el else), al final del archivo. Es mucho más fácil si inviertes el if (si no X, tal => si X, tal) y sigues programando sabiendo que esa condición se cumple y con un nivel de indentación menos:
#24 Hay más cositas. .Net framework top 1 en "otros frameworks", Windows top 1 en "sistemas operativos", vscode y visual studio tops 1 y 2 respectivamente en IDEs. Vamos, menos mal que no aportaron algo bueno que si no...
#100Popularidad != Calidad
De acuerdo con eso, pero hablábamos de "aportaciones", no tanto de calidad. Si se usan sus tecnologías, asumimos que algo bueno habrán aportado.
Microsoft tiene productos de extrema calidad junto a cutreríos impresentables.
De acuerdísimo con eso
#45 Pues cuando cambie lo cambias todo y en paz. Muchas veces se programa anticipándose a cambios futuros que nunca llegan, y al final eso es un error y una enorme cagada porque durante todo el tiempo que pasa desde que está el código escrito hasta el supuesto cambio, estás disfrutando de un código claramente subóptimo.
#c-16" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/16">#16 C# empatado con Bash ... aqui si que he flipado ...
#18 . Para hablar de Software Libre es siempre mejor saber lo que es, y lo que no es, Software Libre.
Otro tema es que te ganes la vida con eso, aunque con tú trabajo creo que les haces un favor también a ellos (a los de M$), y no tengo nada claro si eso es bueno o malo. (CC #3#82)
#c-89" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/89">#89 Los 3 pruductos que he nombrado son Software libre, te dejos sus enlaces al código fuente con sus licencias:
#93 dotnet ahora es libre, en su momento... jajaja un saludo. Y una pena, creo que podría haberle comido mucho mercado a Java en mundo enterprise con tan solo haber hecho que se ejecutase en servidores Linux. Llegaron tarde a la fiesta por desgracia.
#c-99" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/99">#99 C# siempre fue libre, otra cosa es .Net
Como se nota que no tienes ni idea de lo que hablas
vsCode es el editor de código más usado en la actualidad y una maravilla.
Typescript cada día crece más y mejora mucho a JS el lenguaje más usado en la web.
#33#37 Llevo poco en programación, pero entiendo que en casi todo if, no le hace falta un else. En plan que si pasa esto haz esto y ya está, no es necesario remarcar el caso contrario con un else. Supongo.
Está considerado un smell porque aumenta una métrica denominada (en inglés) "cognitive complexity".
Smell no quiere decir que sea malo "per se" o que no se deba usar nunca, sino que hay muchas probabilidades de que ese trozo de código se pueda mejorar.
#41 La cognitive complexity es un arma de doble filo...
He visto montones de códigos mucho más entendibles en un solo método, que distribuidos en complejas estructuras aplicando patrones de diseño.
Incluso a veces, más entendibles que en su versión refactorizada más simple, tratando de sacar código a otra función aunque no tenga una semántica clara, solo para reducir dicha métrica.
#38 Exactamente. En este caso yo declararía una variable al principio del código con el mensaje que quiero mostrar si no es el primer segundo del año, la cambiaría si se cumple el if y siempre, al final, la imprimiría por consola.
#42 Interesante. Para mi la verdad es que se lee bastante mejor "si la fecha es anterior a 2022 di una cosa, y si no, di otra" que "aquí tienes un mensaje, si ya estamos en 2022 lo cambias, y en cualquier caso muestra el mensaje".
#75 Si es un código que sólo quiere poner en marcha en diciembre para eliminarlo a mediados de enero... no hace falta ni el '>' porque el año que viene pondrás otra cosa. Así que te ahorro un par de bytes de código
#77 bueno... La de cosas que eran temporales y quedaron ahí para siempre.
Además ejecutar un "=" o un ">=" lleva el mismo tiempo. Solo ahorramos 1-2 bytes de almacenamiento y unos ciclos de CPU a la hora de pasearlo antes de compilar.
Para hacer eso hay que ser muy cafre.
Mas que nada porque si en el DateTime le pones un ".year" detrás lo comparas con un "2022" y ya está, no hace falta ni comparar si es mas grande o mas pequeño que 2022/01/01, que también sería suficiente.
Es un mensaje del perfil de desarrolladores, quien lo siga lo va a entender y quien no sea programador pero sepa de qué va la cosa también lo entenderá (diría que un "now.year" es suficientemente obvio), no hay excusa de marketing posible en esta tontería.
La verdad es que como código es una puta mierda. ¿Para qué coño tiene C# objetos fecha si va a transformarlos en cadenas para luego hacer mal la comparación?
No me lo puedo creer
jajajajajajajaja yo hice lo mismo pero en JS para mis compas de clase y el mío mola:
const d = new Date();
let day = d.getDate();
let month = d.getMonth() + 1;
let year = d.getFullYear() + 1;
document.open();
function HappyNewYear() !!!! `);
} else
} HappyNewYear();
document.close();
La idea era que la gente pudiera leer la fecha.
Podrían haber, por ejemplo, convertir el string en fecha y luego compararla con la fecha actual, así podrían usar un igual o mayor.
Comentarios
Es un código pensado para que quede bonito, no para que funcione.
Por cierto, el == sí funciona para cadenas de texto, el problema es que no puedes controlar el juego de caracteres que utilizas y puede funcionar distinto dependiendo de la configuración regional de la máquina donde lo ejecutes.
#1 Anda, entonces como el nuevo meneame
#1 Venía de decir lo mismo en #4. El == en cadenas (y en fechas) funciona y compara valores, siendo true cuando son estrictamente iguales.
#1 #5 #14 Todo lo que queráis, pero se considera una mala práctica por algo.
#17 Pero funciona, si no les gusta que lo quiten del lenguaje.
#21 Del lenguaje es algo que no van a quitar nunca, porque joderías el código heredado que quisieras compilar con una nueva versión. Más si cabe cuando no es ninguna mala práctica, simplemente el que lo use tiene que ser consciente de qué resultados va a obtener por la definición del lenguaje. No tendría lógica que en una revisión esos resultados cambiaran.
#32 efectivamente, el operador es perfectamente valido para comparar strings. Otra cosa es que uno lo use sin pensar.
#17 El tipo dice que no se puede usar con cadenas de texto y si que se puede usar. Eso es un hecho. Otra cosa es que lo uses mal, pero mal puedes usar cualquier cosa.
#c-17" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/17">#17 El artículo no habla de malas prácticas, sino de errores. Dice, literalmente que el operador "==", que sólo es utilizable con operandos (es decir, con números, nunca cadenas de texto ni fechas) . Obviando la gilipollez de que sólo es utilizable con "operandos", ya que por definición un operador se aplica siempre a operandos, se equivoca al decir que sólo es utilizable con números. Es falso, y seguramente viene de confundir cómo se comporta el operador == en C# a cómo lo hace en Java. En Java sí se utiliza == sobre dos cadenas o fechas sólo dará true si ambas contienen la misma referencia de memoria. En C# tanto para cadenas como para fechas, lo que se evalúa es el contenido, por lo que es perfectamente viable utilizar ==.
#c-14" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/14">#14 Es que además dice que hay que usar Equals() cuando Equals() sin opciones hace exactamente lo mismo que == pero con el riesgo de comerte un NullReferenceException. Lo dicho en #25, han confundido C# con Java.
#30 debo buena parte de mi sueldo a parchear ese error.... Mira que tengo visto aplicaciones fallar por usar el equals como si fuese java
#c-47" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/47">#47 Sí, lo digo en #25. Como digo ahí también, creo que viene de confundir C# con Java, aunque en Java también se puede "usar" el operador == con strings y fechas. Lo que pasa es que en Java, salvo con primitivas, siempre se compara el valor de los punteros, mientras que en C# con string y datetime se compara su contenido. Aquí voy a especular porque tendría que mirar lo que voy a decir pero creo que es debido a que C# tiene sobrecarga de operadores y Java no y, por lo tanto, puedes definir cómo se va a comportar el == al implementar cualquier Type.
#60 exacto. Además DateTime es un tipo de datos por valor (como el int, byte...) Siempre que se para como parámetro se hace por valor.
#69 Porque es un struct, no una clase.
#73 exacto.
#c-60" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/60">#60 En cualquier caso, para que el algoritmo funcionase, en lugar de == habría que usar >=, y ahí, con un tipo string, que es el chapuceo más gordo del código ya sí que te vuelves loco. Fundamentalmente porque ya no sabes si estás comparando la longitud de la cadena, la transformación de la cadena en número o la transformación de la cadena en fecha. Y ahí ya tenemos que tener mucha imaginación para pensar que se han pegado un curre increíble sobrecargando ese >=.
Lo suyo era usar la biblioteca de funciones propias del tipo Date de C# y dejarse de conversiones que no pintan nada, aunque su objetivo tiene pinta de haber sido que el código lo entendiera intuitivamente la gente que apenas supiera programar.
#80 aunque su objetivo tiene pinta de haber sido que el código lo entendiera intuitivamente la gente que apenas supiera programar
Exacto. El fragmento tiene toda la pinta de estar pensado para que sea código "legible", partiendo de la base que convertir un DateTime a un string para compararlo es absurdo salvo que quieras que uno de los operandos sea "legible" (porque sino habría que inicializar el segundo operando con, por ejemplo, new DateTime(2022, 1, 1), que es menos intuitivo para alguien que no programe. Pero Microsoft se ha encontrado con un gremio bastante puntilloso.
#c-84" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/84">#84 Por eso decimos algunos que para hacerlo realmente útil e igualmente legible con cambiar la comparación de la fecha entera a solamente el año la cosa se habría solucionado (porque, por suerte, en todas las configuraciones regionales el año (gregoriano) se escribe igual):
If (DateTime.Now.Year == 2022) (no soy muy ducho en C# no se si hay que compararlo con un int o un string, pero con comillas o sin ellas, así funciona bien lo que quisieron hacer)
El que no entienda esto tampoco entenderá lo que pusieron originalmente, para qué negarlo.
#84 Al que se le ocurrió utilizar un trozo de código sobre fechas para que fuese intuitivo es que jamás ha trabajado de manera seria con fechas en su vida:
a) O el entorno de programación tiene pocas librerías y funciones y no es ni orientado a objetos y te sale un ladrillo considerable o
b) El sistema es orientado a objetos y tiene bibliotecas en condiciones, pero las llamadas a los métodos de transformación y comparación ya tiran para atrás a cualquier novato.
El lenguaje de los sueños de todo CM:
Si (la_fecha_de_hoy está dentro de 2022) Entonces Escribir "Feliz año nuevo"
SiNo Escribir "Seguimos en 2021"
#17 Es mala practica cuando no sabes que está ocurriendo.
#1 Eso justo venia a decir yo. Funciona por norma general ... mientras no tengas varias configuraciones regionales posibles.
#1 funcionará con el == pero ya puedes tener puntería.
Y a las 00:01 te dice q viajaste al pasado.
De todas formas, hay q ser Cuñao para pedirle solid a una puta felicitación de año nuevo. El frikerio se nos va de las manos.
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/1">#1 Han cambiado lo de "=="
El articulista lee meneame
Una versión previa de este artículo recogía como erróneo el uso del operador "==" en el contexto del citado código: no es así, C# sí permite usarlo como método de comparación de cadenas de texto.
#1 Dependiendo de la configuración regional, la fecha 5 de enero de 2022 puede ser 05/01/2022 o 01/05/2022 o 2022/01/05 o 01-05-2022 ...
En otras palabras, no es una buena práctica comparar fechas de usando cadenas de texto.
Qué rompehuevos es la gente, es evidente que esa lógica no va a funcionar en ningún lenguaje de programación, ahí faltan cosas. Tan evidente como que eso es una gracia y ya está.
Follamos poquísimo...
#23 Tu comentario tendría que ser el trending thread, o como se llame el más importante del hilo
#23 La comparación tal como la han hecho da bastante asco.Lo que me gustaría saber es si lo habían pensado con un bucle sin espera, o cómo.
#31 quizá solo querían mandarlo por el insta.
Eres analista, verdad?
#23 sois informáticos, cómo vais a follar?
#64 juntándonos entre nosotros
#23 Eso es.
Ya se sabe que en meneame se folla muy poco, salvo los admin, que te la meten doblada.
#78 aún es enero, tengo muchas esperanzas para 2022
En caso de funcionar, solo funcionaría en el segundo 0:00:00. Si pasase un segundo, no felicitaría el año nuevo aunque ya estuviésemos en él.
Si fuese un programa que se estuviera ejecutando continuamente, solo mostraría ese mensaje durante un segundo y pasado un segundo de las 00:00:00, diría que seguimos en 2021
¿no sería así?
#6 correcto
#6 Ese es el primer punto del artículo, literalmente.
#20 Tienes toda la razón del mundo.
Seguí leyendo el artículo y me olvidé de eso.
#6, uf, menos mal, estaba leyendo todos los hilos encima tuyo sobre la legitimidad del uso del == y nadie decía nada de la lógica de esa comparación 😅
#6 entiendo que con un cambio == por un >= hubiera válido.aunque hubiera sido más correcto un
#43 No sé hasta qué punto ese operador funciona bien con cadenas de texto...
#43 entiendes que te felicita un día antes, no? la fecha esta bien. A partir del 1 a las 00
#43
No hablo C pero >= creo que no funciona porque la fecha es texto, no un numero.
Pues si vas a redactar un artículo para corregirle los errores a los demás, cerciórate de no cometerlos tú también:
Pero ahí no acababa la lista de errores del código: la comprobación de igualdad entre ambas fechas se lleva a cabo utilizando el operador "==", que sólo es utilizable con operandos (es decir, con números, nunca cadenas de texto ni fechas) y que devuelve 'true' o 'false', por lo que el código elegido no tiene ningún sentido: lo correcto hubiera sido hacer uso del método 'String.Equals'.
Falso. En C# es perfectamente posible utilizar el operador == para comparar tanto cadenas como fechas, utilizándose los valores para realizar la comparación y no los valores de los punteros como pasa con los tipos referencia. El método Equals() es aconsejable para poder comparar cadenas con ciertas opciones, como por ejemplo ignorando mayúsculas/minúsculas, pero usado sin opciones (y validando que quien lo llame no sea nulo) es lo mismo que ==.
#4 Y, dicho sea de paso, un operando no es más que aquello que es objeto de una operación, y puede ser prácticamente cualquier cosa cuando el operador está sobrecargado para que pueda hacer mil cosas diferentes dependiendo del tipo de dato del que sean los operandos. ¿Por qué piensa que un operando únicamente puede ser un número? ¿Nunca estudió lenguajes orientados a objetos? ¿Álgebra?
#37 No hay ningún motivo para usarlos hasta que se demuestre lo contrario:
https://wiki.c2.com/?ElseConsideredSmelly
Por no mencionar que, anidados, suelen provocar un código hadouken:
#39 #41
Gracias, pero como proponéis mostrar el mensaje encerrado en el else?
#c-85" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/85">#85 Si está dentro de un método (y suponiendo que se corrige el problema del "==" cambiándolo por un ">=" o el operador que corresponda en C#, para evitar el error de que se considere estar en 2021 cuando ya es 2022), se me ocurre que se podría añadir un "return" a continuación del mensaje de feliz 2022, para que el método no siga ejecutándose. De esta forma no te haría falta ningún else, el otro mensaje lo pones a continuación sin condición alguna, si ya se ha mostrado el de feliz 2022 el return va a hacer que lo siguiente no se ejecute, y si no cumple la condición de que la fecha ya sea mayor al primer segundo de 2022 entonces es correcto que ejecute lo de 2021.
#85
msg = "Feliz año nuevo"
if (!newyear) ">
print msg
#85 Puedes poner un return al final del cuerpo del if y dejar el contenido del else fuera. O puedes asignar uno de los mensajes a una variable, cambiarlo dentro de un if cuando se cumpla alguna condición y mostrar finalmente el mensaje después del if.
Esas son sólo dos posibilidades. Estoy seguro de que si me paro a pensarlo las encuentro mejores, como por ejemplo algo que implique el uso de expresiones regulares.
Seguro que todo eso se puede al final reducir a una única línea sencilla.
#39
Mira que me harto de corregirle a los novatos ese tipo de composiciones. Sobre todo en validaciones de parámetros, en plan:
if(param != null)
else
Y eso irlo anidando
#59 En este caso sí, es trivial. Pero en código con mucha líneas, si en lugar de usar cláusulas de guarda vas implementando if-else's, cuando llegas a dónde está chicha del código tienes que retener en la mente un montón de condiciones para saber qué se va a ejecutar.
En el código que pone de ejemplo #86, te encontrarías un if al principio del todo y sus consecuencias (el else), al final del archivo. Es mucho más fácil si inviertes el if (si no X, tal => si X, tal) y sigues programando sabiendo que esa condición se cumple y con un nivel de indentación menos:
if (param === null)
// resto del programa
Menuda mierda de todo. Tráiganme el Ferrari que me voy
#24 Hay más cositas. .Net framework top 1 en "otros frameworks", Windows top 1 en "sistemas operativos", vscode y visual studio tops 1 y 2 respectivamente en IDEs. Vamos, menos mal que no aportaron algo bueno que si no...
#27 Popularidad != Calidad
Microsoft tiene productos de extrema calidad junto a cutreríos impresentables.
#100 Popularidad != Calidad
De acuerdo con eso, pero hablábamos de "aportaciones", no tanto de calidad. Si se usan sus tecnologías, asumimos que algo bueno habrán aportado.
Microsoft tiene productos de extrema calidad junto a cutreríos impresentables.
De acuerdísimo con eso
#45 Pues cuando cambie lo cambias todo y en paz. Muchas veces se programa anticipándose a cambios futuros que nunca llegan, y al final eso es un error y una enorme cagada porque durante todo el tiempo que pasa desde que está el código escrito hasta el supuesto cambio, estás disfrutando de un código claramente subóptimo.
Microsoft ni sabe programar ni jamas aportaron algo bueno propio. 🍃
#3 El Excel
#10 El Excel es un entorno de programación disfrazado de producto de ofimática.
#10 copia barata
#3 ¿Cómo va todo en el año 2000?
#11 he pensado lo mismo. A día de hoy Microsoft está empezando a ser la mejor opción y Windows la mejor plataforma para desarrollar.
#34 Discrepo contigo en el segundo punto. Estando dotnet disponible en linux, éste sigue siendo el mejor entorno de desarrollo.
#3 El buscaminas del Windows
#3 Bendito excel
#3 La mayoría de desarrolladores no piensa como tú
https://insights.stackoverflow.com/survey/2021#most-popular-technologies-language
#c-16" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/16">#16 C# empatado con Bash ... aqui si que he flipado ...
#24 porque no eres devops
#3 claro que si campeón cuéntanos más.
VsCode, Typescript, C#… gracias Microsoft por todo ese software libre de excelente calidad que me hace ganarme la vida.
#18 basura de entornos que ademas son privativos. Ale
#18 . Para hablar de Software Libre es siempre mejor saber lo que es, y lo que no es, Software Libre.
Otro tema es que te ganes la vida con eso, aunque con tú trabajo creo que les haces un favor también a ellos (a los de M$), y no tengo nada claro si eso es bueno o malo.
(CC #3 #82)
#c-89" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/89">#89 Los 3 pruductos que he nombrado son Software libre, te dejos sus enlaces al código fuente con sus licencias:
VsCode - https://github.com/microsoft/vscode (Licencia MIT)
Typescript - https://github.com/microsoft/TypeScript (Licencia Apache 2.0)
C# - https://github.com/dotnet/csharplang
Que tu odies a la empresa privada es tu problema.
#93 dotnet ahora es libre, en su momento... jajaja un saludo. Y una pena, creo que podría haberle comido mucho mercado a Java en mundo enterprise con tan solo haber hecho que se ejecutase en servidores Linux. Llegaron tarde a la fiesta por desgracia.
#c-99" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3605212/order/99">#99 C# siempre fue libre, otra cosa es .Net
#93 no te lo crees ni tu, en cuanto los usas pagas por todo. 🍃
#82 Basura dice jaja.
Como se nota que no tienes ni idea de lo que hablas
vsCode es el editor de código más usado en la actualidad y una maravilla.
Typescript cada día crece más y mejora mucho a JS el lenguaje más usado en la web.
#94 ni pu ta idea, defender a Microsoft y sus productos es de memos. 🍃
#3 El Basic de muchos ordenadores ochenteros.
#3 Respuesta de cuñado con palillo en la boca
#68 cuñado es el que usa windows, ale
#83 Otra respuesta de cuñado.. y seguro que yo instalé mi primer linux mucho antes que tú, en aquellos tiempos de Slackware
#98 tu jugabas con linux cuando yo ya dominaba el Unix, el OS400 y la Novell, novatillo. 🍃
#3 El paint.
#3. Efectivamente. Escribir programas que "funcionan" no evita la medioctidad a la que nos han tenido desde siempre acostumbrados los de Micro$oft.
El tema de reventar estándares
esde dentro en beneficio propio o de comprar y remendar software de terceros mejor lo dejamos para otro hilo.
Se nota que Menéame se ha generalizado y ya no es un nicho de programadores en que nadie ha comentado aún que usar un "else" es un smell.
Mucha teoría de bootcamp y Udemy pero poco más.
(Y con esto me acuesto, esperando levantarme con un saco de negativos )
#33 qué problema hay con ese else?
#33 #37 Llevo poco en programación, pero entiendo que en casi todo if, no le hace falta un else. En plan que si pasa esto haz esto y ya está, no es necesario remarcar el caso contrario con un else. Supongo.
#38 #37
Está considerado un smell porque aumenta una métrica denominada (en inglés) "cognitive complexity".
Smell no quiere decir que sea malo "per se" o que no se deba usar nunca, sino que hay muchas probabilidades de que ese trozo de código se pueda mejorar.
#41 La cognitive complexity es un arma de doble filo...
He visto montones de códigos mucho más entendibles en un solo método, que distribuidos en complejas estructuras aplicando patrones de diseño.
Incluso a veces, más entendibles que en su versión refactorizada más simple, tratando de sacar código a otra función aunque no tenga una semántica clara, solo para reducir dicha métrica.
#44 Ahí es donde entra en juego la experiencia. Por eso decía que un smell no es una regla escrita en piedra.
#38 Exactamente. En este caso yo declararía una variable al principio del código con el mensaje que quiero mostrar si no es el primer segundo del año, la cambiaría si se cumple el if y siempre, al final, la imprimiría por consola.
#42 Eso está bien... Hasta que el código cambie, o tengas un tercer caso que no imprima, y tengas el mismo problema.
#42 Interesante. Para mi la verdad es que se lee bastante mejor "si la fecha es anterior a 2022 di una cosa, y si no, di otra" que "aquí tienes un mensaje, si ya estamos en 2022 lo cambias, y en cualquier caso muestra el mensaje".
#37 Absolutamente nada, es sencillo y se entiende a la perfección.
Ni funciona ni es bonito.Es un código horrible, de esos que daña a la vista.
Como la mayoría de cosas en Internet, quieres hacer una gracia y terminas con discusiones y debates de como corregir o mejorar al locutor.
Hola,
¿Es aquí donde se viene a criticar Microsoft a destajo?
(no voy a negar que lo estoy disfrutando)
#36 positivo al canto! Jajajajajajajaaaa cojo sitio...
If (DateTime.Now >= new DateTime(2022, 1,1))
Y andando... Funciona, y no depende de la configuración regional.
#65 #66 acepto tu parche:
If(DateTime.Now.Year >= 2022)
#75 Si es un código que sólo quiere poner en marcha en diciembre para eliminarlo a mediados de enero... no hace falta ni el '>' porque el año que viene pondrás otra cosa. Así que te ahorro un par de bytes de código
#77 bueno... La de cosas que eran temporales y quedaron ahí para siempre.
Además ejecutar un "=" o un ">=" lleva el mismo tiempo. Solo ahorramos 1-2 bytes de almacenamiento y unos ciclos de CPU a la hora de pasearlo antes de compilar.
Ese parche no lo acepto en el git.
#96 Joé, qué finolis eres, mecagontó.
Los ofendiditos del código. Anda e iros a picar código a vuestra cárnica por mil eurillos al mes y dejad de dar la vara
Para hacer eso hay que ser muy cafre.
Mas que nada porque si en el DateTime le pones un ".year" detrás lo comparas con un "2022" y ya está, no hace falta ni comparar si es mas grande o mas pequeño que 2022/01/01, que también sería suficiente.
Es un mensaje del perfil de desarrolladores, quien lo siga lo va a entender y quien no sea programador pero sepa de qué va la cosa también lo entenderá (diría que un "now.year" es suficientemente obvio), no hay excusa de marketing posible en esta tontería.
La verdad es que como código es una puta mierda. ¿Para qué coño tiene C# objetos fecha si va a transformarlos en cadenas para luego hacer mal la comparación?
Lo único que tendría que haber hecho nuestro merluzo es pasarse por aquí https://docs.microsoft.com/es-es/dotnet/api/system.datetime.compare?view=net-6.0
Y cambiar dos chorradas para que el código felicitara el año.
No me lo puedo creer
jajajajajajajaja yo hice lo mismo pero en JS para mis compas de clase y el mío mola:
const d = new Date();
let day = d.getDate();
let month = d.getMonth() + 1;
let year = d.getFullYear() + 1;
document.open();
function HappyNewYear() !!!! `);
} else
} HappyNewYear();
document.close();
EDIT (repetido)
No conozco C#, pero... ¿No tienen while ahí?
#7 tiene los mismos bucles que C y a mayores el foreach.
#7 tienes:
while
do-while
for
foreach
Podría haber sido peor, podría haber sido el código de Windows 11.
#12 A ver si tú te crees que el panel de control no lo quitan del todo por nostalgia...
La idea era que la gente pudiera leer la fecha.
Podrían haber, por ejemplo, convertir el string en fecha y luego compararla con la fecha actual, así podrían usar un igual o mayor.
Ahora entiendo lo de teams...