SubMain.com
Google+
YouTube
RSS

Code Contracts: A Technique to Cut Down on Bugs

Carlos SchultsArticles, CarlosSchults, CodeQuality1 Comment

Two Hands Handshake signifying code contractsRent, employment, house buying: you name it. If you’re an adult, chances are that you’ve signed several contracts in your life (and will probably sign many more). A contract is an agreement that defines the rights and obligations of two or more parties in order to accomplish something.

Having a proper contract in place is a powerful tool to clear doubts about what you’re allowed or not allowed to do to the apartment you live at, for instance. A contract also defines penalties for the parties that fail to fulfill their part of the agreement. If you don’t put down your house payments when they’re due, you’re pretty much guaranteed to suffer some consequences.

Contracts are everywhere in the real world. But what would it look like if we could use something similar to contracts in our code? For instance, what if we could specify “clauses” that defined the conditions required at the start and end of a function? Or maybe that specified and enforced the invariants of our objects? In this case, I’d say our programs would definitely improve in readability, safeness, and self-documentation.

And now, what if I told you something like this already exists?

(more…)

exasperated programmer with her head on a desk resenting code review practices

The 4 Code Review Practices That Make Devs Quit

Carlos SchultsArticles, CarlosSchults, CodeReviewsNo Comments

If we start with the premise that having code reviews is better than not having them, the next step is to figure out how to make them better. And though we’re all aware that code reviews are a good thing, they can quickly degenerate into toxic scenarios. We don’t want that.

In this post, we’re going to see four code review practices that can make developers feel frustrated and alienated. In the more extreme cases, developers might even leave a company to escape from what they perceive as tyrannical, nonsensical demands. Keep reading to learn what those practices are, how to avoid them, and how to leverage the benefits of automation in your code reviews to prevent many of these toxic scenarios from happening in the first place

Once you know that, you’ll be empowered to turn your code reviews into healthy processes that lead to higher code quality and more happiness for the developers in your team. Let’s get started! (more…)

CodeItRight_Rules_21

CodeIt.Right Rules Explained, Part 21

Carlos SchultsArticles, CarlosSchults, CodeIt.RightNo Comments

Welcome to another installment of the “CodeIt.RightRules Explained” series. If the previous sentence doesn’t mean anything to you, don’t despair—here’s a quick recap.

CodeIt.Right is one of the SubMain’s offerings. You can think of it as an automated code review tool, which puts it into the category of static code analyzers. CodeIt.Right checks your source code against a set of rules, which could be the default set or ones customized by you.

In this ongoing series, we focus on the standard, pre-packaged sets for obvious reasons: those are the ones that will apply to everyone. In each installment of the series, we explain three CodeIt.Right rules so that you know why you should or shouldn’t deactivate the rule when using CodeIt.Right.

Speaking of which, we tend to start these posts with the following sentences:

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

Basically, you can condense these two rules into: “Always understand a suggested fix.” But we prefer to present them as two separate rules to emphasize the choice you have in front of you: ignore the warning or implement a fix. If you decide to ignore the warning, do it only when you understand the implications. If you go for the fix, make sure you know what you’re doing and why implementing the fix benefits your code.

With that out of the way, let’s get to today’s rules.

(more…)

Datetime mistake

“String Was Not Recognized as a Valid DateTime.” Why It Happens and How to Avoid It.

Carlos SchultsArticles, CarlosSchults, CodeQualityNo Comments

Ah…error messages. Sometimes very useful, other times not so much, but always present in a developer’s life. And that’s what today’s post is about. Not “error messages” in general, but one message in particular: “String was not recognized as a valid DateTime.”

As a developer, you’re pretty much guaranteed to have to write code that handles date and time. Which means you’re also bound to have some problems while parsing strings to DateTime values, and that’s what this post will cover.

We’ll start out by talking about the causes of the issue. You’ll learn about globalization and how big a role it plays in the consistency and correction of your application. Then, we’ll close with practical advice on what you can do to prevent such problems from happening in the first place. Let’s get started!

(more…)

Man shrugging, trying to figure out why intellisense isn't working

Visual Studio IntelliSense Not Working? What To Do.

Carlos SchultsArticles, CarlosSchults, General2 Comments

There are certain tools that have become indispensable for developers in this day and age. These tools often start as “nice-to-haves” but quickly graduate to “must-haves” due to the benefits they provide. Once you get used to relying on them, it’s terribly frustrating when you’re prevented from using them for some reason. And there’s a very specific tool in that category I want to talk about today. It’s called Visual Studio IntelliSense.

This intelligent code completion tool present in Visual Studio is definitely a must-have for a .NET developer. The .NET Framework BCL (Base Class Library) is just too large for a human brain to grasp. There’s no way you could remember all those classes, interfaces, and methods. Being able to put a period after some variable and get a nice list of all the possible members you can call isn’t only a nicety: it’s a survival need. So, what to do when you need Visual Studio IntelliSense but, for whatever reason, it’s not working? That’s what this post is about.

We’ll start out by doing a quick overview of Visual Studio IntelliSense. We’ll cover a little bit of history, plus a few definitions, so you can grasp why this tool is more than a simple autocomplete. Then we’ll proceed to cover the different solutions you can try to get you out of this nightmarish scenario.

We’ll then close the post with quick advice on how to get IntelliSense to work for your own classes and types.

(more…)

CodeItRight_Qualimark_with_bag_of_code

Automated Code Reviews: 5 Manual Checks You Can Automate

Mark HenkeArticles, CodeQuality, CodeReviews, MarkHenkeNo Comments

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, looking over one file at a time. Oftentimes we miss things; perhaps we’re tired or distracted by other tasks.

Why not do to our own processes what we do to others: automate them? After all, computers will be better at handling some of these checklist items than we are.

(more…)

Clock_with_bugs_as_hour_markers

How Much Time Do Programmers Spend Debugging? Too Much

Mark HenkeArticles, CodeIt.Right, CodeQuality, CodeReviews, MarkHenke1 Comment

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.

(more…)

c struct example with flowers

C# Struct: Definition, Examples, Best Practices, and Pitfalls

Mark HenkeArticles, CodeBasics, MarkHenkeNo Comments

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.

(more…)

You need me in code comment

4 Reasons Why We Need Code Comments

Mark HenkeArticles, CodeBasics, CodeQuality, GhostDoc, MarkHenkeNo Comments

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.

(more…)

CodeItRight_Rules_20

CodeIt.Right Rules Explained, Part 20

Carlos SchultsArticles, CarlosSchults, CodeIt.RightNo Comments

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 showcase the flexibility and breadth of the ruleset.

Readers of this series know that we like to start these posts by stating two things:

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

Yeah, you could simplify this down to “always understand a suggested fix.” But I choose to not put it that way since I want you to really think and consider your options. If you decide to ignore a fix, do so understanding the consequences. On the other hand, if you accept a suggested fix, do it with a full understanding of how that’s going to benefit your application.

With all that in mind, let’s get to today’s rules.

(more…)

Menu