Software Quality Blog - SubMain Software - Code Quality Tools, Automated Code Review and Refactoring

What Are the Biggest Code Commenting Fails You’ve Seen?

September 18, 2018Sylvia FronczakArticles, CodeIt.Right, GhostDoc, SylviaFronczakNo Comments

We often focus on code fails. But what else have we seen and done that makes us drop our heads in shame and frustration? What else do we laugh (and cringe) at when reading code? The comments!

Whether they’re redundant, unreadable, confusing, or there’s just no comments at all, we can learn a lot from failure. And to spice things up, I’m going to throw in a biking analogy. You’re not sure if that’ll work? Me neither. But let’s go on this ride together and find out.

(more…)

Model Binding: A Dead Simple Guide With Everything You Need to Know

September 11, 2018Rodney SmithArticles, General, RodneySmith3

In an ASP.NET MVC project, the model binder is a feature of the framework that performs a lot of the heavy lifting behind the scenes. In this article, we are going to talk about everything you need to know to get the most out of model binding, with an eye toward simplicity.

But before we can do that, we need to go through what things looked like before model binding arrived on the scene.

(more…)

CodeIt.Right Rules Explained, Part 19

September 4, 2018Carlos SchultsArticles, CarlosSchults, CodeIt.RightNo Comments

Welcome to another installment in the “CodeIt.Rules Explained” series. Not familiar with the series? Or maybe even with CodeIt.Right itself? Don’t worry, we’ve got your back.

CodeIt.Right is a static analyzer tool. More specifically, it’s an automated code review tool and a really awesome one at that. CodeIt.Right works by checking your source code against a collection of rules, giving you instant feedback about its quality, and even offering automatic corrections to many of the issues.

We usually start out these posts with our rule of thumb for deciding whether or not to ignore a suggested fix:

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

I won’t mind if you think I’m trying to be funny by wording it that way. But I assure you that’s not the case. I really believe it makes a difference when you put it that way, as two different sentences. This is by design. It’s meant to emphasize the choice you have in front of you: ignore the suggested fix or implement it. If you decide to ignore it, do so only when you’re completely aware of the risks.

The same thinking applies if you decide to go for it. By all means, accept a suggested fix if you feel like it, but do so only when you’re completely aware of the benefits it’s going to generate.

(more…)

The Death of WinForms Has Been Greatly Exaggerated

August 28, 2018Peter MorlionArticles, General, PeterMorlion31

Depending on your age and experience as a .NET developer, you might or might not be familiar with the technology known as Windows Forms. Windows Forms, or WinForms, was introduced together with .NET 1.0 in 2002. It was the first desktop UI technology for .NET. We’re now 16 (!) years later, and WinForms runs on the latest version of the .NET Framework (currently 4.7.2) and .NET Core (currently 2.1). But because it’s so old, has been succeeded by WPF and UWP, and only runs on Windows, many assume WinForms is dead. And while it certainly has some wrinkles on its face, it’s not just dead yet. Don’t believe me? Keep reading.

(more…)

App.Config: Basics and Best Practices

August 21, 2018Peter MorlionArticles, CodeBasics, PeterMorlionNo Comments

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 article is applicable to web projects, but there are subtle differences. That is why I’ll only focus on the app.config.

(more…)

Where Self-Documenting Code Falls Short

August 14, 2018Sylvia FronczakArticles, CodeBasics, Documentation, SylviaFronczak3

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?

(more…)

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

August 7, 2018Carlos SchultsArticles, CarlosSchults, CodeBasics, CodeQuality6

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.

(more…)

Using CodeIt.Right to Create Visual Basic Coding Standards

July 31, 2018Carlos SchultsArticles, CarlosSchults, CodeIt.Right, CodeQualityNo Comments

Here on the SubMain blog, I’ve already covered how to use CodeIt.Right to Create C# Coding Standards. Today Visual Basic gets the same treatment. In case you haven’t read the previous post (or any post in this blog at all), I’ll briefly explain what these posts are about.

CodeIt.Right is an automated code review tool. It checks the source code of your application against a set of rules (which can be the standard rules or custom ones), giving you instant feedback on its quality.

Similarly to the previous post, I’ll explain how you can create a Visual Basic coding standard by using CodeIt.Right. If your team doesn’t already know and use coding standards, then that’s a great opportunity for all of you to learn about all of the benefits you’re missing out on. I’ll begin by arguing that you need a coding standard. The SubMain blog has already covered that subject, but I’ll quickly revisit it.

Then I’ll go on to explain the usual problems teams face when trying to implement coding standards and code reviews in a totally manual way.

Lastly, I’ll explain how automation can solve those problems and how can you do so with the help of CodeIt.Right.

(more…)

CodeIt.Right Rules Explained, Part 18

July 24, 2018Carlos SchultsArticles, CarlosSchults, CodeIt.RightNo Comments

Time for another post in the CodeIt.Right Rules Explained series. In case you haven’t read any of the posts in the series, here is a short explanation.

CodeIt.Right is an automated code review tool, which analyzes the code of your application code against a set of rules, giving you instant feedback on its quality. Each post in this series explains three of those rules.

If, on the other hand, you’re a follower of this series, nothing above is any news to you. You’ll also know that we always start the post 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.

Nope, we’re not trying to sound clever, funny, or anything. I know it’s obvious to you that we could just say, “always understand what the tool is telling you.”

We don’t say it that way, though, and there is a reason for that. We want to make it very clear you have two options: to either implement the suggested fix or ignore the warning whatsoever. If you implement the fix, you should do so when you are fully aware of why that makes your code better. If you ignore it, you should also be aware of the dangers of doing so.

With that said, let’s get started with our first rule for today.

(more…)

I’ll Delete Your Commented Code Without Reading It and I’m Not Sorry

July 17, 2018Melissa McEwenArticles, CodeIt.Right, GhostDoc, MelissaMcEwenNo Comments

I was knee-deep in a mess of undocumented legacy code. I wasn’t even sure who had authored this code, but whoever it was, they had long departed to places unknown. The code was in a language I didn’t even really know. And the bug was marked “critical.” If I didn’t fix it, an entire academic department website would display totally incorrect information.

It was then I encountered the “thing.” A large commented out block of important-looking code. Was it left behind by an ancient civilization? Could it help me? Or was it a beast placed into a jail of a comment block to protect innocent coders?

I call this “comment junk,” and my life’s mission is now to delete as many of these trash piles as possible. Here’s how I do it.

(more…)