SubMain.com
YouTube
RSS

PeterMorlion

Home Category: PeterMorlion

The Death of WinForms Has Been Greatly Exaggerated

Peter Morlion62 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.

winforms_arent_dead_submain

Don’t believe me? Keep reading.

(more…)

app_config_submain_checkmark

App.Config: Basics and Best Practices

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

Lines of code

Understanding the .NET Build Configuration System

Peter Morlion3 Comments
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.

Ignoring the maze

9 Tips for Simplifying Your Code Documentation

Peter Morlion2 Comments

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

StyleCop: A Detailed Guide to Starting and Using It

Peter Morlion32 Comments

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

Too much commented out code in your codebase will have you pulling your hair out, like this poor guy.

Commented Out Code Is Junk In Your Codebase

Peter Morlion3 Comments

Why do we have the tendency to comment out code instead of just deleting it? The reason is that we don?t want to lose a piece of code that might come in handy in the future. Maybe we think we?re still going to need it because it solves some problem in an elegant way. Or maybe it?s because it helps us when debugging.

It all boils down to fear of losing information. But commented out code will get in the way more than it will help you, and it’s better off being deleted. I?ll expand on why below and provide some possible alternatives.

Why Commented Out Code Is a Problem

1. It Distracts

At the very least, commented out code will distract you and your team members from the actual code. It?s tempting to think our brains can filter out the commented blocks or that just a few lines won?t make our minds wander. But in reality, the commented out code is just an extra hurdle your brain needs to jump when trying to make a mental model of what the code is doing. And that by itself is hard enough, even in very clean codebases.

2. It’s a Source of Code Rot

More often than not, commented out code will start to ?rot.? The longer code stays commented out, the higher the chances it no longer fits when uncommented.

One possibility is that it just doesn?t compile anymore. The codebase will likely have changed, and the live code will have evolved with it. But the commented out code will still be as it was when you put it in comments.

A more dangerous situation could arise if the code does compile but the behavior of any underlying code is altered. The commented out code may make calls to other components whose behavior has changed. This means the commented out code no longer does exactly what it was intended to do. That’s a potentially be a dangerous problem, and it means you’ll be wasting your time trying to find the cause of an obscure bug. In both cases, it?s a risk to the team and the company, and one that could have been avoided.

Finally, the commented out code may have been a good idea at the time, but fast forward several months or years and you can probably come up with a better solution. Languages, frameworks, and techniques evolve, and in time you will have acquired more knowledge, causing you to solve a problem in a different way. Trust your future self to solve the problem that the commented out code solved.

So how can we avoid the problems caused by commented out code without losing our piece of code forever?

(more…)

Menu