Articles Archives - Page 7 of 14 - Software Quality Blog

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

May 15, 2018Carlos Schults2

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.

Want to know if you're getting it right as you learn C#?

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

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

9 Tips for Simplifying Your Code Documentation

May 1, 2018Peter Morlion2

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

C# Array: An Introductory Guide for Getting Started

April 17, 2018Justin Boyer2

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.

Want to know if you're getting it right as you learn C#?

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

(more…)

StyleCop: A Detailed Guide to Starting and Using It

April 10, 2018Peter Morlion31

Content updated: 4/23/2019.

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 Under Microscope

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.? This post will walk you through the following:

What Stylecop is.
How to install and run it.
Configuration.
Integration into your build.
Defining rule excpetions
Analyzing all projects
Using the command line

So, read on if you want to learn everything there is to know about Stylecop.
(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…)

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

March 13, 2018Carlos Schults8

It’s possible that the post title above left you scratching your head. Functional programming in C#. Is that even a thing?? Well, it’s definitely a thing. Allow me to clarify.

Most people would classify C# as 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.

C# Lambda logos illustrating C# Functional Programming

Make no mistake. Using functional-programming-inspired features is not the same as programming in a pure functional language, like Haskell. Or even a hybrid language but with stronger emphasis on the functional side, like F#.

However, employing functional programming concepts can improve the quality of your code. 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…)

CodeIt.Right Rules Explained, Part 14

March 6, 2018Erik Dietrich1

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