C# Constructor: Usage, Examples, Best Practices, and Pitfalls
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, 
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.
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.
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.
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.
When you first start out with C#, you’ll surely begin by creating a class. This is true whether you’re creating the code by hand or having a tool do it for you. The class is one of the most basic elements of the C# language. It serves many purposes, but the main purpose is for grouping related functions.
Code review is one of the most common topics here on the SubMain blog. Today’s post covers this subject again, this time attacking a very specific angle: code review tools. If you’ve been a software developer for a while, you’re probably familiar with at least a few of them.
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,