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#.
Does the term “XML comments” confuse you? Well, rest assured. You’re not alone. “Does that refer to comments inside an XML file?” you might wonder. Or maybe you have this vague notion that it has something to do with some kind of documentation for programming source code. Both assumptions are kind of right. But you’re still reading this post, which means that “kind of” isn’t going cut for you, right?
So this post is all about XML comments. You’re going to learn what this term actually means, what XML comments are (and aren’t) good for, and learn a thing or two about software documentation. If you’re ready, then let’s get started!
“Everything automatable will eventually be automated.” Have you heard that saying? I’d prefer to tweak it a little bit and say that everything automatable should be automated. If you’re a regular reader of the SubMain blog, you’ll know that we enthusiastically advocate for automation. In today’s post, we continue that trend, focusing on documentation generation. More specifically, we’ll walk you through some essential features you should consider when trying to pick a C# documentation generator. (more…)
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. If you’re looking for reasons why you should know this, Mark Henke does a nice job explaining four good reasons.
Now, let’s follow tradition by starting with the basics and working our way to more advanced concepts as we go along.
We’ve already covered so many C# concepts, and most of them relate to objects. This is hardly surprising, C# being an object-oriented language. What is surprising is that, up until this point, we haven’t covered the “thing” responsible for creating objects!
Today’s post will remedy this problem by covering the C# constructor. The post will roughly follow the same pattern we’ve followed through much of the series. We start by defining the concept, then proceed to show several usage examples. We part ways with general tips on best practices to follow and pitfalls to be aware of. Let’s begin!
C# is about objects, classes, and class methods. The runtime handles memory management so you don’t have to. Your C# code is compiled into an intermediate language and runs on the .NET platform. It’s a language built around productivity; therefore, the compiler does many optimizations so you can write clean, readable code.
There are some general standards that fluent C# writers follow. So, if you’re a developer who’s coming to C# from another programming language, you’ll want to know this stuff too! This post is an introduction to the most important standards and sets you on the course to other resources that can help build your C# prowess.
If you’re a software developer, then I’d bet you use some kind of automated testing. And if you don’t, you certainly should. But what about “automated documentation?” Do you know what this means? Are you putting this technique to work for you? Most likely you’re not. And if that’s the case, you’ve come to the right place.
We’ll start out by exploring the role documentation plays in the modern software development world, which has, by and large, embraced agile methodologies. The post will show that yes, documentation is important and valuable even today.
Then we’ll proceed to cover automated documentation. We’ll start by examining the growing trend of using automation to improve the software development process itself, showing how automation has become a must for companies struggling to remain competitive. After that, we’ll define automated documentation and talk about the benefits it provides.
Finally, we’ll get to the tools, where we’ll briefly cover three tools that can help you and your team with your automated documentation strategy, sharing some final tips after that.
Let’s get started.
If you’re a regular reader of the SubMain blog, you’ll know that we often publish posts about fundamental concepts of the C# language. Today’s post adds yet another chapter to this ongoing series. The topic we’ll cover is, in fact, as fundamental as it can get: C# data types.
As the title suggests, this post will cover the three most common C# data types. For each one of the types, we’ll start out by offering some justification on why the type deserves to be on the list. Then, we’ll proceed to show you some interesting facts you need to know about the type. When relevant, you’ll also see some code examples.
But before we start, there are two questions that need answering. First, what is our definition of a C# data type? And what does it actually mean for a type to be “common”?
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.
There are many ways to make sure that code written for a professional team meets requirements around styling and complexity. Every team should be doing peer code review before code is promoted to production. This review ensures not only that your code does what it’s supposed to, but also that other people can understand it, and that it meets the team’s style requirements.
Like manual code review, automated code review is a critical part of writing high-quality code.
You’re a little ways into your first programming job, and things are getting easier. At first, all the code you had to deal with might have overwhelmed and confused you, but you’re starting to get the hang of it. That’s great! Now you’re wondering how to take the code you write to the next level. While there are lots of things to learn about your programming stack, many of which will make you a better programmer, there are a few that will serve you no matter what stack you work in. One of those is code documentation.
Many developers don’t write enough documentation, either because they don’t see the value or because they feel like they don’t have time. You don’t need to be one of those developers. With a little time and a lot of practice, you can add documentation for your code that makes reading it a joy to use for both you and anyone else who comes along.
