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

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

April 24, 2018Erik DietrichArticles, CodeIt.Right, ErikDietrich, RulesNo Comments

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, JustinBoyer1

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, RulesExplainedNo Comments

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 SchultsArticles, CarlosSchults, CodeIt.Right, CodeQualityNo 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…)

C# Lambda logos illustrating C# Functional Programming

Functional Programming in C#: Map, Filter, and Reduce Your Way to Clean Code

March 13, 2018Carlos SchultsArticles, CarlosSchults, CodeQuality3

C# is supposed to be an object-oriented language, but it’s possible that you, as a .NET/C# developer, have been using functional programming concepts without even knowing it.

And that’s what today’s post is about. I’ll just first briefly cover the attractions of functional programming and why it makes sense to apply it even when using a so-called object-oriented language. Then I’ll show you how you’ve already been using some functional style in your C# code, even if you’re not aware of it. I’ll tell you how you can apply functional thinking to your code in order to make it cleaner, safer, and more expressive. (more…)

VS2017 v15.6 Compatibility Releases

March 9, 2018Serge BaranovskyCodeIt.Right, GhostDoc, News, Releases, UpdatesNo 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.

Products updated include –

GhostDoc v5.9 – all editions
CodeIt.Right v3.3 – all editions
GhostDoc Pro v2018 Beta

Download GhostDoc v5.9

Download GhostDoc v2018 Beta

Download CodeIt.Right v3.3

CodeIt.Right Rules Explained, Part 14

March 6, 2018Erik DietrichArticles, CodeIt.Right, CodeQuality, ErikDietrich, Rules, RulesExplainedNo Comments

Today, I’m doing another post in the CodeIt.Right Rules Explained series. For anyone who hasn’t seen one of these before, here’s briefly how it works. CodeIt.Right is an automated .NET code review tool, and it has a lot of rules to help you. In the posts in this series, I explain those rules in detail.

Whenever I post in this series, I start with my two rules of thumb for static analysis.

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

As always, I’ll explain that I don’t phrase it this way because I think I’m clever. I could just say, “Figure out why the tool is suggesting this.” But I specifically opt not to.

The reason I do this is that whenever the tool confronts you with a warning, you have a choice: address the warning or ignore it. And in either case, you should make your choice for the right reasons. Are you ignoring it because you’ve determined that the pros of having it outweigh the cons the tool is warning you about? Or are you ignoring it because you don’t feel like dealing with it? The same thing also applies on the side of implementing fixes.

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

(more…)

Is Visual Basic Dead?

February 27, 2018Erik DietrichArticles, ErikDietrich, General3

Is Visual Basic dead? Yup. Wow, hey, that might have been the easiest blog post I’ve ever written. See ya next week!

Oh, wait. You probably want me to justify this claim somehow, don’t you? And then you probably want me to add support for the argument, nuance in position, and something actionable. Alright, fine. Have it your way.

Is Visual Basic Dead? Let’s Define Dead: Zombies and Nothingness

First, the nuance. To continue with the dead metaphor, let’s consider two subtly different flavors of dead:

First, you have truly dead languages, fading into nothingness and complete obscurity. Think, for instance, of Pascal, which has plummeted on the TIOBE index from a peak of third most popular to today’s position of 136th, putting it behind every language you’ve ever heard of and 50 you haven’t.
Then you have zombie languages. Zombie languages die out of the realm of first-class, maintained languages but refuse to stop running the software of the world. I’m looking at you, COBOL.

What determines whether a language rests quietly in its grave or goes lurching around the countryside, terrorizing companies with legacy applications in their portfolio? Well, obviously there are countless factors involved. But I’d argue that the languages most likely to zombify are the ones that enjoyed the most prolific adoption within the risk-averse, cost-conscious enterprise. For instance, the worlds of government and banking have no shortage of green screens and mainframe applications upon which they rely to this day.

So is Visual Basic dead? Again, yup. But I would argue that it’s a zombie language rather than a language fading to nothingness. As an industry, we collectively rapid-prototyped a lot of WinForms and VBA things into existence, many of which keep chugging along to this day.

But, But, But…

I’ve introduced nuance but not really any reasoning or evidence so far. And I can imagine some objections to what I’m saying.

(more…)

Quick Tips for Better C# Security

February 20, 2018Justin BoyerArticles, CodeIt.Right, JustinBoyer4

Application security is a hot topic. No one wants to write code that leads to the next data breach or major headline. C# security is on the minds of many .NET developers.

Secure coding involves detailed knowledge of a programming language and framework. There could be dozens of rules articulated here with detailed code examples showing right versus wrong coding practices. However, that might lead to quite a bit of dry reading and low retention. Instead, I’ll take a different angle. I’ll describe three principles that lead to strong, secure coding practices. Learn these principles well, and you’ll be able to secure any application you build.

(more…)