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

CodeIt.Right Rules Explained, Part 22

February 12, 2019Carlos SchultsNo Comments

CodeItRight_Rules_22 Welcome back to the CodeIt.Right Rules Explained series. For those of you who haven’t seen an installment in this series, let’s explain what it’s all about.?CodeIt.Right?is a tool that performs automated code review for .NET. It checks your code against a set of rules, giving you valuable feedback on its quality. Throughout the series, we’ve been explaining these rules, always three at a time.

In every post in this series, we start with the following two rules of thumb:

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

Trust me?we don’t phrase it this way to sound funny or anything. It’d be the same thing to say ?figure out why the tool is suggesting this.? But we don’t. And here’s why.

Each time CodeIt.Right shows you a warning, you must decide to either address it or ignore it.?Make that choice for the right reasons. Ignore the warning when you’re truly convinced it doesn’t apply to your situation or doesn’t provide enough benefits. Don’t ignore it because you don’t understand it very well and don’t feel like handling it.

Now that you understand what this post is all about, let’s get to today’s three rules.

(more…)

CodeIt.Right Rules Explained, Part 21

January 2, 2019Carlos SchultsNo 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…)

How Much Time Do Programmers Spend Debugging? Too Much

November 27, 2018Mark Henke1

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

CodeIt.Right Rules Explained, Part 20

November 6, 2018Carlos SchultsNo 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…)

Web.config: What It Is and 5 Common Mistakes to Avoid

October 23, 2018Mark Henke2

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 post, I’ll show you how. We’ll look at five of the most common configuration mistakes and how to avoid them.

Want to prevent runtime issues and design problems?

Download a free trial of CodeIt.Right and get an instant, automated code review.

(more…)

Treat Warnings As Errors. I Mean It. You Need to Do This

October 2, 2018Carlos Schults6

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.

(more…)

code_review_prep_runner_preparing_for_race

Code Review Prep: 4 Tips to Eliminate Inefficiency

September 25, 2018Carlos SchultsNo Comments

Code review is, hands down, one of the most fundamental best practices a software shop can employ to produce better software. A good code review practice can shed light on design problems, improve the readability of the code, and spread knowledge throughout a team. It also helps you find bugs early (when it costs less to fix them).

Code reviews sound like a gift from the heavens, right? While far from being a panacea, I’d say they are a spectacular tool to ensure software quality?when done correctly. And that, of course, is the tricky part. It doesn’t take much for a code review practice to go downhill. If you’ve been a developer for at least a few years, then I’d bet you have your share of scary stories to tell.

But that’s not what we’re here to talk about today. Forget the truly horrific stories?toxic workplaces and the like. Today we’re going to cover inefficiency in code reviews. Or, more precisely, we’ll offer you tips on how you can avoid it.

So, without further ado, let’s get to it: four tips that will help you when preparing to implement a code review practice in your software shop.

(more…)

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

September 18, 2018Sylvia FronczakNo 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…)

CodeIt.Right Rules Explained, Part 19

September 4, 2018Carlos SchultsNo 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…)

Using CodeIt.Right to Create Visual Basic Coding Standards

July 31, 2018Carlos SchultsNo 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…)