Software Quality Blog - SubMain Software - Page 2 of 20 - Code Quality Tools, Automated Code Review and Refactoring

Writing that says "rules, you must, you must not"

Using CodeIt.Right to Create C# Coding Standards

June 5, 2018Carlos SchultsArticles, CarlosSchults, CodeIt.Right, CodeReviews, TeamStandardNo Comments

Does your team use a coding standard? If the answer is no, then I’m afraid you’re missing out on a lot of important benefits. This post will help you create (and automate) C# coding standards using Submain’s CodeIt.Right. I’ll start out by making the case that you need a coding standard. We here at the SubMain blog have already covered that subject, of course, but I’ll revisit it anyway.

With that out of the way, I’ll go on to explain the most common problems that occur when teams try to implement coding standards and code reviews manually.

Finally, I’ll show you how automation can heal these pains, and how to use CodeIt.Right for doing so. Let’s get started. (more…)

Is XML Dying?

May 29, 2018T.J. SimmonsArticles, GhostDoc, TJSimmons4

Since the beginning, web developers have always needed to transport and store data, and there’s an entire generation of web developers that has only ever used JSON (JavaScript Object Notation) for that purpose. That choice makes sense; JSON is easy to read and conforms to JavaScript syntax. Some developers may not have even heard of XML (eXtensible Markup Language). XML was also designed to be both human- and machine-readable. Its purpose is primarily to handle the transportation and storage of data. And this data exchange was not meant for web only. Most importantly, distributing data of different flavors works fantastically well with XML, all because XML is designed to be highly flexible within a strict structure. Yet JSON continues to be the first choice for many developers. Which prompts the question: is XML dying?

In this article, we will explore the differences between XML and JSON. We will address which conditions best suit which format. At the end, we’ll dig into a few scenarios where XML will continue to play a crucial role in data exchange.

(more…)

Understanding the .NET Build Configuration System

May 22, 2018Peter MorlionArticles, CodeIt.Right, PeterMorlion2

When you create a .NET application in Visual Studio, it contains two build configurations: Debug and Release. But what does this mean exactly? Most developers will tell you that you can transform your Web.config or App.config based on the selected build configuration. For example, when you select “Debug,” your database connection string might point to a database on your PC (i.e. “localhost”). Then, when you select “Release,” it could point to the production database.

But the build configuration system in .NET goes beyond just transforming the config file. There is a whole system of solution and project configuration management that you can use to your advantage.

A project configuration contains a set of properties to be used when building the project. Likewise, a solution configuration contains a set of properties at the solution level. But it also contains the selected project configurations for that solution configuration. An example should clarify.

(more…)

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

May 15, 2018Carlos SchultsArticles, CarlosSchults, CodeBasics, CodeQuality1

Not that long ago, we published a post about the fundamentals of the C# array. Today’s post will continue the trend, covering the C# list. Don’t worry: if you’re a beginner, you’ll also benefit from this post. Instead of brushing up, you’ll get your first contact with this incredibly useful data structure.

As in the array post, we’ll discuss what a list is. We’ll learn how to use it, what its most common operations are, and how to avoid some common pitfalls. With that in mind, you’re ready to see what the C# list has to offer you.

(more…)

CodeIt.Right Rules Explained, Part 16

May 8, 2018Erik DietrichArticles, CodeIt.Right, ErikDietrich, RulesExplained1

Today, we bring you another post in the CodeIt.Right Rules Explained series. Up until this point, I’ve been chronicling these posts by their number in the series, but I realize that the numbering: is both academic and relatively easily inferred via the posting category. Nevertheless, in spite of changing the approach to the title, I’ll recap the premise, as I always do.

CodeIt.Right is an automated .NET code review tool. That means that it automatically analyzes your code and applies rules to it. In the posts in this series, I explain those rules in detail.

In all posts in this series, I start out by listing these rules of thumb for static analysis in the hopes that repetition makes the point.

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’ll also explain, as I always do, that I don’t use this phrasing to seem clever or because I can’t figure out the more succinct logical conclusion that these two statements imply: that you should always understand why the tool is suggesting a fix.

I do this because static analyzer warnings present you with a choice: address the warning or ignore it. And, whichever path you choose, you should do so deliberately and for the right reasons. Decide to ignore the warning because you think what you’re doing isn’t actually a problem. Or decide to address the warning because you understand that what you’re doing is problematic and not because you’re programming by coincidence. Always know what you’re doing.

And with that, let’s dive into today’s rules.

(more…)

9 Tips for Simplifying Your Code Documentation

May 1, 2018Peter MorlionArticles, Documentation, GhostDoc, PeterMorlion2

Documenting your code is important. It tells other developers what the code does, why it is constructed in a certain way, and how to use it. Good documentation saves them time when they are trying to perform a certain task that isn’t straightforward. It will probably also save you time because the human brain can only store so much information. Even your own code will confuse you at some point in the future.sp

Even though code documentation is important, many developers find it tedious. This is exacerbated by the fact that many companies associate code documentation with long Word documents that must be kept up to date manually. Not exactly developer heaven.

So how can we simplify code documentation while still keeping it effective? (more…)

5 Ideas for Rules to Add to Your CodeIt.Right Profile

April 24, 2018Erik DietrichArticles, CodeIt.Right, ErikDietrich, Rules1

A while back, I wrote on the subject of code review horror stories. This was mostly for fun, but it does speak to an important truth. Code reviews can be pretty contentious, unpleasant, and even counterproductive when done wrong.

I could spend a bunch of time today talking about how to do them right. But I won’t. Instead, I’ll talk about ideas for how to automate your way around possible points of contention. I’m nothing if not a software developer at heart.

Automated Code Review Goes Beyond the Default Rules

You might be wondering how one “automates around” contentious code reviews. Perhaps you think I’m proposing some kind of pie-in-the-sky scheme to say, “Alexa, review my code.” But no. I’m talking about extending CodeIt.Right’s automated review capabilities.

I have a long-running series on this blog, explaining CodeIt.Right’s automated code review rules. In those posts, I talk about how you should be very deliberate about either heeding the tool’s advice, or deciding to ignore/deactivate a given rule.

But I never really talk about the idea of adding your own rules.

And that’s what we’re going to do today. You don’t have to use a tool like CodeIt.Right only for its out of the box capabilities when it offers you a rich customization platform backed by a fully featured API. You can write your own rules.

And you should write your own rules. Developers waste an awful lot of time in code reviews endlessly rehashing checks that could be automated easily. And just because it’s something perhaps more specific to your team that hasn’t yet been automated doesn’t mean that you can’t automate it—and pretty easily, at that.

So let’s take a look at five ideas for rules you should add to your CodeIt.Right profile.

(more…)

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

April 17, 2018Justin BoyerArticles, CodeBasics, CodeQuality, JustinBoyer2

So you’ve started your journey into C# development. Learning any new language or framework can be a challenging road. However, you need not despair. Allow those who have gone before you to lead the way and guide you on your journey. Today’s leg of the journey is the C# array.

In this post, we’ll discuss what an array is. We’ll see how to use one in our code, and we’ll discuss how best to use it and what pitfalls can hurt your code quality.

(more…)

StyleCop: A Detailed Guide to Starting and Using It

April 10, 2018Peter MorlionArticles, CodeAnalysis, CodeQuality, PeterMorlion, StudioTools1

Put two developers together and they’re bound to have a discussion about coding style. No two developers write code in the exact same way. More often than not, one isn’t better than the other and it’s just a matter of taste. In a team or in a single project, it’s more important to be consistent than it is to choose the right style. Agreeing on a style can be hard enough, but enforcing it shouldn’t be something you do manually. It will be tedious and error-prone.

StyleCop is a tool that can automate this. Let’s have a look at how to set it up and what it brings to the table.

(more…)

CodeIt.Right Rules Explained, Part 15

April 3, 2018Erik DietrichArticles, CodeIt.Right, ErikDietrich, RulesExplained1

It’s time again for another post in the CodeIt.Right Rules Explained series. We’re fifteen posts deep into the series now, as you can see from the title. But if you haven’t seen these posts before, I’ll recap the same information I cover in each intro.

CodeIt.Right is an automated .NET code review tool (both C# and VB), and it has a lot of rules to help you. In the posts in this series, I explain those rules in detail.

In all posts in this series, I start out by listing these rules of thumb for static analysis in the hopes that repetition hammers them home.

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

And as always, I’ll explain that I don’t use this phrasing to be cute or because I can’t figure out the logical implication of these statements: “always understand why the tool is suggesting a fix.”

I do this because whenever a static analysis tool confronts you with a warning, you face a choice: address the warning or else ignore it. And, either way, you should act intentionally and for the right reasons. If you’re ignoring it, do so because you think the pros of your warning-triggering code outweigh the cons implied by the warning. Don’t ignore it because you don’t understand and don’t feel like doing it. And on the other side of the coin, don’t change your code simply because some tool tells you to. Always understand why you’re changing your code, or else you’re programming by coincidence.

All that said, let’s look at today’s three rules.

(more…)