Why do we need code comments? I would not be surprised if your first answer is, “We don’t.” I get it. Senior developer after senior developer has taught us that “comments are bad.” And we cheerfully nod our heads, saying, “I am smarter for not using them.” We grin smugly when we see one of our juniors make the “mistake” of using comments in their code. But as much as we sometimes abuse them, we still need comments. I know comments don’t affect the code’s behavior. I understand how they can get stale and stop making sense. I am all for…
Time to cover yet another construct of the C# language. In this series, we’ve already covered the C# list, array, and string, to name a few. Today’s post is a little bit different, though. Its subject isn’t a data structure or type, but instead, a decision structure: the switch statement. Le’s get started!
In one of my previous posts, I wrote about the .NET build configuration system. I mentioned the app.config file, but didn’t really dive into it. So let’s take a closer look at this file now. When you create a (non-web) .NET Framework application in Visual Studio, an app.config file is added to your project. When you create a class library or a .NET Core project, such a file is not included, although it can be done afterward. In a web project (i.e. ASP.NET) you will use a similar file, the web.config. A lot of what I will cover in this…
You’re a clean coder. You use descriptive names for everything. You’ve refactored your app into a shrine of single responsibilities. Even your slightly crazy, off-the-grid uncle can follow the code. (Hi, Uncle Joe!) The app not only documents itself, it documents life. Or does it? Are there things you might have missed? Is there subtle context you’re going to forget between now and next week? And what crazy coding gems are you going to find a few months from now when you go to add a new feature? Where does self-documenting code fall short?
It’s time for yet another discussion on an important C# construct. We started this journey with the C# array. Then we covered the list and enum. And, finally, the dictionary. Today, we cover yet another fundamental but often misunderstood type in C#: the string.
So far we’ve had the opportunity to take a deep C# dive on arrays, lists, and the very valuable enum. Today we are going to stay in the System.Collections.Generic namespace and learn about a structure that’s designed for lookups—the C# dictionary.
We’ve discussed arrays and lists in C#. This time, we’ll take the same journey with a funky little type called the enum. C# enums are very useful constructs, but they have some quirky behavior that can bite you if you’re not careful. Let’s now see what makes enums tick, how to use them effectively, and what to be careful of when using them.
Not that long ago, we published a post about the fundamentals of the C# array. Today’s post will continue the trend, covering the C# list. Don’t worry: if you’re a beginner, you’ll also benefit from this post. Instead of brushing up, you’ll get your first contact with this incredibly useful data structure. As in the array post, we’ll discuss what a list is. We’ll learn how to use it, what its most common operations are, and how to avoid some common pitfalls. With that in mind, you’re ready to see what the C# list has to offer you.
So you’ve started your journey into C# development. Learning any new language or framework can be a challenging road. However, you need not despair. Allow those who have gone before you to lead the way and guide you on your journey. Today’s leg of the journey is the C# array. In this post, we’ll discuss what an array is. We’ll see how to use one in our code, and we’ll discuss how best to use it and what pitfalls can hurt your code quality.