CodeIt.Right Archives - Page 3 of 13 - Software Quality Blog

CodeIt.Right Rules Explained, Part 18

July 24, 2018Carlos SchultsNo 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 McEwen1

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…)

CodeIt.Right Rules Explained, Part 17

June 19, 2018Erik Dietrich1

It’s time for a deep dive into yet another three CodeIt.Right rules.? In case you’ve missed it, this continues a post series in which we, well, do a deep dive into the CodeIt.Right Rules.

CodeIt.Right?is an automated code review tool, making it fall under the broad heading of static analyzers.? It checks your source code against a set of rules, both ones that you customize?and a set that comes out of the box.? In this series, we’re focusing on the latter, since those are the ones that will obviously apply to everyone.

Followers of this series will know that I always kick the posts off by listing two static analysis rules of thumb that I advertise as good ideas.

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

If this seems a little obtuse, it’s probably because you could condense these two rules into a single one by logical implication: “always understand a suggested fix.”

But I deliberately choose not to phrase it this way, opting for the two separate rules.? I do this to emphasize your choice: ignore the warning or implement a fix.? If you decide to ignore the warning, you should do so only when you’re fully aware of the risks of doing so.? If, on the other hand, you decide to fix the warning, you should always understand what you’re doing when you change your own code.? Otherwise, you’re programming by coincidence.

Don’t program by coincidence.? Instead, take a look at today’s three rules.

(more…)

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

Using CodeIt.Right to Create C# Coding Standards

June 5, 2018Carlos SchultsNo 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…)

Understanding the .NET Build Configuration System

May 22, 2018Peter Morlion3

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…)

CodeIt.Right Rules Explained, Part 16

May 8, 2018Erik Dietrich1

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…)

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

April 24, 2018Erik Dietrich1

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…)

CodeIt.Right Rules Explained, Part 15

April 3, 2018Erik Dietrich1

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…)

Sharpen the Saw: 4 Quick Tips for Your Dev Team

March 27, 2018Carlos SchultsNo Comments

Are you familiar with the expression “sharpen the saw” in the context of learning and continuous improvement? If you’ve read Stephen Covey’s?The 7 Habits?of Highly Effective People, then I’m sure you are. For those unfamiliar with the term, it basically means to engage in practices that will make you better at your craft without necessarily involving the craft itself.

What can you as a tech lead, lead developer, or software architect do to encourage the developers on your team to sharpen their saws? That’s what we’ll to answer with this post. We’ll show you four quick, easy ways your team can improve their skills and deliver more value.

(more…)

VS2017 v15.6 Compatibility Releases

March 9, 2018Serge BaranovskyNo Comments

Today we have made available compatibility update releases for GhostDoc and CodeIt.Right.

This update addresses the “Visual Studio still loading the project.” message and other issues after upgrading VS2017 to the v15.6.