The official Twitter account of the Windows Dev Center de Microsoft, the website that brings together news and resources for programmers, decided to welcome the new year 2022 with a nice tweet that showed the code of a short program that would be in charge of congratulating us on the new year from the console once the running PC detected the change of year.
We could think that it was just one of the thousands of tweets that, from corporate accounts, sought to stand out by launching an ingenious tweet to their audience. But the tweet had a problem: that the code was a botch, at all levels.
And of course, that is not something that should be seen in a Microsoft account aimed at software developers and less when handling code in C #, a language created and developed by Microsoft itself. So the person responsible for the account chose to delete the tweet when the first responses from users began to arrive.
The programmer career in 2017 and in the future (with Javier Santana)
A code with more errors than lines
We say that it is a botch, in the first place, because as it is proposed, it would show the congratulations for the new year during the first second of the year -good-, but from the following second -when the condition established in the IF— it would start to show a message again indicating that we are still in 2021 – according to the ELSE of the loop—.
Second, the use of the method ToString(), although functional in this case, it is certainly not optimal when comparing dates with each other:why convert the DateType data type to a text string to compare with another date, when DateType is perfectly usable in this context?).
In addition, the format of the reference date itself (that of the first second of 2022) is poorly expressed: when converting the DateType to String, the C # language does not insert a ‘0’ before the single digit numbers, which means that 01/01/2022 could never exist —Yes, it would do so on 1/1/2022 — so the code in the tweet would never detect the change of year.
Scott Hanselman, himself a developer of Microsoft’s Web Platform Team, explains it in a video posted a few hours ago on his YouTube channel:
In any case, this error indicates a trend: as the disaster of the ‘Effect 2022’ of Microsoft Exchange has also revealed in these days, Microsoft developers seem to have a habit of managing date formats in ‘creative’ and potentially catastrophic ways.
But the list of errors in the code did not end there: the equality check between both dates is carried out using the “==” operator, which is only usable with operands (that is, with numbers, never text strings or dates) and that returns ‘true’ or ‘false’, so the chosen code doesn’t make any sense: the correct thing would have been to use the method ‘String.Equals‘.