CodeIt.Right for VS2022
CodeIt.Right v2022 is now available!
- Added Visual Studio 2022 integration
- Added x64 development environment support
Visual Studio is 64-bit
The most exciting news about Visual Studio 2022 is that it will be 64-bit. This is a giant leap forward as far as the memory available to the Visual Studio environment!
Due to the existing Visual Studio being a 32-bit process, it can only use a maximum of 4 GB of memory. That memory is shared between the project files, the runtime, the extensions, and the VS environment itself. So regardless of how powerful your development rig is, current Visual Studio can only use some 4GB of memory, even if you got 32GB available.
VS2022 being x64 is excellent news! Especially if you have large solutions!
What does this mean for CodeIt.Right?
Since both CodeIt.Right is a Visual Studio extension and exists within that VS environment’s memory space, both will be taking advantage of the “breathing freedom” that a 64-bit environment provides.
Will Visual Studio x64 improve CodeIt.Right performance?
It will! It is hard to tell at this point how great the improvement will be but just by the mere fact that on large solutions, our products won’t have to offload data to a drive cache and keep in memory – provides a massive improvement in performance!
Older version licenses
Note to the CodeIt.Right users: The v2021.x (or earlier) license codes won’t work with the v2022. For users with License Protection and active Software Assurance subscription, we will be sending out the v2022 license codes. Alternatively, you can retrieve your v2022 licenses at the My Account page right now. Users without the License Protection or with expired Software Assurance subscription will need to purchase the new version. Currently, we are not offering an upgrade path other than the Software Assurance subscription. For information about the upgrade protection see our Software Assurance and Support – Renewal / Reinstatement Terms
“Code cleanup” is a phrase that sounds like it’s a lot of work. Well, sometimes it may be an arduous task, indeed. But that doesn’t mean it’s the way it should be. As with many things in software development—and in general life—it’s often more comfortable, less painful and more productive to do an unpleasant task every day, little by little than let it accumulate and become a monster.
A good code review can feel like magic. A skilled code reviewer will deftly work through each part of a pull request, noting potential problems and proposing elegant solutions. If you’re like many developers, you recognize a good code review when you see one. You’ve probably even created a few yourself. But you’re probably also a bit unsure as to how to make sure that your code reviews are good every time.
Every programming language has operators. Operators are the components of the language that, well, operate on variables mostly. Most C# operators are symbols such as % and ??. And some are words, like async and is. In this guide, you’ll see all of them, including an example of each one. We’ll start with the operators that are common among programming languages and end on some that are more specific to C#.
C# is about objects, 
When you’re coding by yourself, for yourself, your code style doesn’t matter that much. Developers the world over have GitHub profiles full of horrible, ugly code they wrote to tinker with some new library or language. Their goal wasn’t to write pretty code, it was to learn something new. That changes when you’re working in a software team, though. Now you need to make sure not only that your code is functional, but that it adheres to team standards.
Many people have explored the concept of code reviews at length. They continue to be an integral part of the developer experience, for reasons I will discuss below. But, like most things that challenge us to improve, they can easily become awkward and a host for a variety of toxic behaviors. A number of articles have been written about proper code reviews, and they usually center around the idea of “being nice.” But I’m going to hone in on a few slightly different signs of toxicity in your code reviews. And with each sign, I’ll help you understand how you can change your team’s behavior to create a healthier environment.