We’ve all been in that situation where you’re streaming along, banging out some sick code for a new feature. You’re excited to see how many minds you’ll blow when you demo it. And then you see a blip on your radar. Something is going wrong with your production system. Oh no. You give it a cursory look and you realize you don’t understand what’s going on. At this point, you know your day is shot. Why? Because you already know you’ll need to spend too much time debugging.
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…
Time for yet another deep dive into three more CodeIt.Right Rules. For those of you who don’t know about our CodeIt.Right Rules series, here’s a brief explanation. CodeIt.Right is one of the tools offered by SubMain. It’s a static code analyzer tool or, more specifically, an automated code review tool. CodeIt.Right works by checking your code against a set of rules and giving you instant feedback on how to solve potential problems. It even offers automatic fixes when applicable. In each installment on this ongoing series, we explain three CodeIt.Right rules, usually picked from as diverse a category as possible, to…
It seems easy for people to say things like “LOL, Web Forms” or “Web Forms is dead.” Web Forms sometimes gets very little respect from the .NET development community. We look forward in time, forgetting the giants on whose shoulders we stand. It was the dominant way of making websites in .NET for many years. Is it really a remnant of a bygone era? Or does it have a vibrant existence in places oft overlooked?
We as software developers have created several disciplines for coding: test-driven developments, clean code principles, and screaming architecture, to name a few. However, we often find our web.config files can sprawl out of control. We just don’t pay as much attention to our configuration as we do to our classes and methods. The good news is that many mistakes are easily avoided, and with a little discipline we can put our configs on par with the rest of our codebase. In this article, I’ll show you how. We’ll look at five of the most common configuration mistakes and how to avoid them.
You’re checking out some code. It’s been a long time since you looked at this project. Or maybe it’s the first time. You point your editor at an interesting file name and double-click to open it. Your coffee is warm, your mind is clear, and you’re ready to go. And there it is, sticking out like white socks in sandals. A spelling error. How do you handle it? Do you fix it? Do you ignore it? Discuss it with the author? Bring it up during lunch when he’s not around?
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!
We here on the SubMain blog love to talk about programming best practices. Sometimes we’ll cover topics that are specific to C# or .NET as a whole. Other times, however, we write about concepts that are universal. Today’s post falls into the latter category. And I’ll start out by making a strong claim: you absolutely should treat warnings as errors when developing in .NET. Well, to be honest, that applies to virtually any platform. The examples in this post, as usual, will be in the C# language. But as we’ve said, the concept applies pretty much everywhere.
Code review is, hands down, one of the most fundamental best practices a software shop can employ to produce better software. A good code review practice can shed light on design problems, improve the readability of the code, and spread knowledge throughout a team. It also helps you find bugs early (when it costs less to fix them). Code reviews sound like a gift from the heavens, right? While far from being a panacea, I’d say they are a spectacular tool to ensure software quality—when done correctly. And that, of course, is the tricky part. It doesn’t take much for…