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#.
You need this version if you want to use GhostDoc with Visual Studio 2019.
Note to the GhostDoc v2018 users: The v2018.x (or earlier) license codes won’t work with the v2019. For users with License Protection and active Software Assurance subscription, we will be sending out the v2019 license codes. Alternatively, you can retrieve it on 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
By now, we all know Ctrl+C and Ctrl+V like the backs of our hands. Heck, some developers write entire programs using these copy/paste shortcuts! But what about using other shortcuts to make yourself more efficient?
That’s right, I’m talking about Visual Studio comment shortcuts. You may be aware that the Ctrl+K, Ctrl+C chord creates a comment, but there’s a bit more magic to it than the shortcut alone. This post will delve into some details about context, language, and efficiency when it comes to comments in Visual Studio. Let’s follow tradition by starting with the basics and working our way to more advanced concepts as we go along.
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.
Time for another C#-related post. We’ve already covered a fair amount of the language’s keywords, types, and concepts in previous posts. Today’s post covers comments, a topic that you might think is trivial. My mission in this post is to convince you otherwise. True, comments are far from being the most exciting programming topic you could think of, I admit. And sure, comments have gotten a negative reputation over the years. But there’s more to comments than you might think.
In this post, you’ll learn about the definition of C# comments, followed by common justifications for their usage. Then we’ll proceed to show you the different possible types of C# comments and how to use them in practice. Let’s get started.
If I were to summarize DateTime.Now using one word, it would be “don’t.” DateTime.Now is a very problematic way of retrieving the current date and time, and you should—almost—never use it.
But that would make for a super short post and an incredibly unhelpful one at that. It’s not enough to say you shouldn’t use a given approach without going further to explain why it’s problematic and what to do instead.
So, that’s what we’re going to do now—take a look at the dos and don’ts of DateTime.Now as well as a few best practices and alternatives. Let’s get started.
Software documentation is all about bringing clarity into a code baseline. It provides clues to clarify the meaning of certain code structures. For this purpose, we use best programming practices and tools to clarify our software. When documenting software, we aim to minimize time spent hunting for meaning. We want anyone using or reading our code to know exactly what we meant when we wrote it. In addition, they should also know how to use our code without having to look for extra clues. Whether it’s an API, a suite of REST services, or simply a method in your code, it should all be clear. When things are not clear, you have to dig up the meaning from other parts of the code, and this is a waste of time.
In this article, we’ll explore what information to document and how to do it. Lastly, we will talk about presenting our software documentation.
Welcome back to the CodeIt.Right Rules Explained series. For those of you who haven’t seen an installment in this series, let’s explain what it’s all about. CodeIt.Right is a tool that performs automated code review for .NET. It checks your code against a set of rules, giving you valuable feedback on its quality. Throughout the series, we’ve been explaining these rules, always three at a time.
In every post in this series, we start with the following two rules of thumb:
Trust me—we don’t phrase it this way to sound funny or anything. It’d be the same thing to say “figure out why the tool is suggesting this.” But we don’t. And here’s why.
Each time CodeIt.Right shows you a warning, you must decide to either address it or ignore it. Make that choice for the right reasons. Ignore the warning when you’re truly convinced it doesn’t apply to your situation or doesn’t provide enough benefits. Don’t ignore it because you don’t understand it very well and don’t feel like handling it.
Now that you understand what this post is all about, let’s get to today’s three rules.
A minor feature update build v2018.2.19030 is now available
<inheritdoc /> tag instead of copying the base member documentation. Note: When using the <inheritdoc />, remember it is a custom tag and you must use GhostDoc to generate help documentation and VS Intellisense files.<inheritdoc /> tag instead of copying the base member documentation – when UseInheritdocTag setting is True.For the complete list of changes, see What’s New in GhostDoc v2018
We appreciate your feedback on the new features; please email us at support@submain.com or post in the GhostDoc Forum.
One of the most anticipated acts at a circus is the juggler—a performer who can move five or six or more balls in the air at the same time. The really complicated juggling acts, however, add something extra to wow the crowd. The juggler first climbs some stairs, high up but still close enough for everyone to see. He’s on a platform. The overhead lights are dim while one bright spotlight is on the juggler as he starts to juggle—one, two, three, four, five, and six balls moving effortlessly through the air, all in balance. He’s good!
But now, a new spotlight illuminates everything to his right … and everyone is amazed. It’s a tightrope that runs across the entire stage to another platform. The juggler then turns and faces the tightrope while juggling the six balls, and he starts walking slowly across. Step by step, balancing and juggling, he gets to the other side. He then turns to face the crowd, catches each ball, and bows. The crowd roars in delight! He’s done!
In many ways, a software developer is a juggler who is keeping many balls in the air while simultaneously walking on a tightrope. If you drop any balls or you walk in the wrong direction, you will fail. If, on the other hand, you get to the right destination with all the balls in the air, you get to stop, take a bow, maybe get some applause, and be done with your software.