I am curious about how infrequent automated code reviews seem to be in the workplace. As software developers, we pride ourselves on our ability to automate away other people’s problems. Much of what we do is scrutinizing manual work done by our customers or business stakeholders. We find tasks that could be performed more efficiently, automate them, and the customer hopefully praises our efforts. Yet it seems that we rarely scrutinize our own work. Manual code reviews run rampant on many software teams. We take our “expert opinion” and turn it into either a mental or written checklist. Then we apply the checklist through manual labor,…
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.