SubMain.com
Google+
YouTube
RSS
Warning equals Error

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

Carlos SchultsArticles, CarlosSchults, CodeIt.Right, CodeQuality3 Comments

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

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

Facepalm emoji over commenting fails

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

Sylvia FronczakArticles, CodeIt.Right, GhostDoc, SylviaFronczakNo 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…)

model_binding_guidebook_SubMain

Model Binding: A Dead Simple Guide With Everything You Need to Know

Rodney SmithArticles, General, RodneySmith3 Comments

In an ASP.NET MVC project, the model binder is a feature of the framework that performs a lot of the heavy lifting behind the scenes. In this article, we are going to talk about everything you need to know to get the most out of model binding, with an eye toward simplicity.

But before we can do that, we need to go through what things looked like before model binding arrived on the scene.

(more…)

CodeItRight_Rules_19_SubMain

CodeIt.Right Rules Explained, Part 19

Carlos SchultsArticles, CarlosSchults, CodeIt.RightNo 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…)

winforms_arent_dead_submain

The Death of WinForms Has Been Greatly Exaggerated

Peter MorlionArticles, General, PeterMorlion35 Comments

Depending on your age and experience as a .NET developer, you might or might not be familiar with the technology known as Windows Forms. Windows Forms, or WinForms, was introduced together with .NET 1.0 in 2002. It was the first desktop UI technology for .NET. We’re now 16 (!) years later, and WinForms runs on the latest version of the .NET Framework (currently 4.7.2) and .NET Core (currently 2.1). But because it’s so old, has been succeeded by WPF and UWP, and only runs on Windows, many assume WinForms is dead. And while it certainly has some wrinkles on its face, it’s not just dead yet. Don’t believe me? Keep reading.

(more…)

app_config_submain_checkmark

App.Config: Basics and Best Practices

Peter MorlionArticles, CodeBasics, PeterMorlionNo Comments
In one of my previous posts, I wrote about the .NET build configuration system. I mentioned the app.config file, but didn’t really dive into it. So let’s take a closer look at this file now.

When you create a (non-web) .NET Framework application in Visual Studio, an app.config file is added to your project. When you create a class library or a .NET Core project, such a file is not included, although it can be done afterward.

In a web project (i.e. ASP.NET) you will use a similar file, the web.config. A lot of what I will cover in this article is applicable to web projects, but there are subtle differences. That is why I’ll only focus on the app.config.

(more…)

self_documented_code_falling_short

Where Self-Documenting Code Falls Short

Sylvia FronczakArticles, CodeBasics, Documentation, SylviaFronczak3 Comments

You’re a clean coder. You use descriptive names for everything. You’ve refactored your app into a shrine of single responsibilities. Even your slightly crazy, off-the-grid uncle can follow the code. (Hi, Uncle Joe!) The app not only documents itself, it documents life.

Or does it?

Are there things you might have missed? Is there subtle context you’re going to forget between now and next week? And what crazy coding gems are you going to find a few months from now when you go to add a new feature?

Where does self-documenting code fall short?

(more…)

codeitright + visual basic drawing

Using CodeIt.Right to Create Visual Basic Coding Standards

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

Menu