This article is more than 1 year old
Microsoft rang in the new year with a cutesy tweet in C#. Just one problem: The code sucked
When marketing meets coding
Microsoft has ushered in 2022 with an amusing (and now deleted) tweet from its Windows Developer account that answers oh so many questions about the quality of code emitted from Redmond nowadays.
As is so often the case, the code (which looked like it aimed to greet 2022 with a perky "Happy New Year") doesn't appear to have troubled a reviewer before going live. Taking aside the fact that it's going to whinge about it still being 2021 when it isn't, there's also the use of the
ToString() method when other properties might well have done the job better. And why the "
Still, it's the thought that counts. One should consider oneself fortunate that one's own well-intentioned coding cockups have never plopped out of the social media orifice of a company with a market cap in the trillions.
Memories of having to deal with the frankly barking mad US date format still haunt your correspondent to this very day. And then there were the time zones to worry about...
- Microsoft patches Y2K-like bug that borked on-prem Exchange Server
- US Government Accountability Office explains why it sustained Microsoft's protests over $10bn NSA contract
- When product names go bad: Microsoft's Raymond Chen on the cringe behind WinCE
- Microsoft closes installer hole abused by Emotet malware, Google splats Chrome bug exploited in the wild
The tweet attracted the usual barrage of supportive and helpful comments typical of Twitter, including a meme from one of Microsoft's own coding boffins, Scott Hanselman, who later followed up with a useful video he described as "an overly detailed analysis of a bad DateTime comparison in C#."
https://t.co/wxwQcJ9oWY pic.twitter.com/qjtT1RXcwo— Scott Hanselman (@shanselman) January 3, 2022
The video is well worth a watch, not least because it delves into not just the obvious flaws in the code but also other considerations that need to be taken into account when handling dates.
As for the original code... well, at best it'll probably keep insisting it is 2021 aside for one brief second. And let's face it, even that isn't right. As another commenter observed: "Yeah 2021 is wrong. We're still stuck in 2020." ®