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#.
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.
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.
The C# interface isn’t exactly intuitive. Interfaces, in general, are common. We use them all the time. You’re using at least one interface right now as you read this article. Keyboards, mice, and screens are interfaces to your operating system. It’s the same concept with C# interfaces.
In this article, I’ll start with these familiar device interfaces as a metaphor for explaining the C# interface. I’ll use examples and alert you to some of the pitfalls. You’ll also learn about industry best-practices when using C# interfaces. By the end, you should have a clear picture of the C# interface.
Ahh, C# structs: a classic carryover from the C/C++ days. Have you ever used one? Wondering how they work? Well, they are similar to classes with some substantial differences. Structs have niche value to us as C# developers. You don’t often need them, but there are some things they do better than classes.
They also come with some caveats. Let me walk you through all this through a series of code examples.
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 writing clean code, and I do my best to ensure my variables, methods, and class names describe their intent as accurately as possible. If I see dead code lying around in the comments for a while, I delete it.
But here is the bottom line: we need code comments because there are some things they do better than plain code. Here’s why.
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!
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.
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?