Content that is all about programming and coding! Find examples of code often written in C# along with tutorials.
In this article I'll be going over one of my most used design patterns called the facade (or façade), and explaining why I like to use it. As with all things I share information about, it's important to remain pragmatic as software engineers. With that said, this article is not to persuade you to use this pattern exclusively or that there are not alternatives. Instead, I'd like to arm you with another design pattern tool in your figurative coding toolbox. The more tools you have available, the better prepared you are to go build awesome stuff. What We're Trying to Achieve With a Facade When I am developing software, whether it is personally, professionally, or as someone that is influencing the direction of software I am not directly coding myself, I encourage a focus on flexibility in software. I have…
I wanted to create a follow-up post in my series on IEnumerables, iterators, and collections focusing on performance characteristics. When checking out the runtime performance and memory characteristics between these materialized collections and iterator benchmarks, I was very surprised! Check out this article for performance benchmark characteristics and some curious finds.
This article is in response to an answer I wrote on Quora. As an engineering leader, does it make sense to approach things as hands-on management and writing code? Let's see when it makes sense, and when it doesn't.
I've been making it my mission more recently to try and reduce the barriers for people that want to get started with programming. If you're just getting started out, it can be incredibly intimidating and often leaves folks quitting before they get started. When you factor in just how many programming languages there are to pick from, it's yet another barrier for getting started. How do you pick? What's the best one? I’ve spoken before about how to approach getting started and if you’re open to starting with the “dotnet” ecosystem then this C# basics article is for you! For some history, C# was originally created back in 2000 although if you check out this other page, we can see that it looks like C# 1.0 was actually out in 2002. For homework, you can go read about all of…
This article is not set out to try and persuade you, the reader, that either using an iterator or materialized collection will universally solve your problems. Both iterator and materialized collection usage can be used to solve the scenarios that we'll be looking at, but both will come with a different set of pros and cons that we can further explore. The purpose of this article is to highlight scenarios based on real world experiences where either an iterator or materialized collection was being misunderstood, misused, and ultimately leading to a pile of headaches. As you read this article, if you find yourself saying "Well, sure, but they should have..." you're probably right. The problem is fundamentally not the usage of an iterator or the materialized collection, but not understanding how to consume them effectively. So I hope that when…
As C# programmers, we've all been burned by asynchronous EventHandlers. And if you still haven't yet, then hopefully this article will arm you for being able to better navigate long debugging sessions where functionality mysteriously stops working in your application. While there are several different solutions for dealing with async event handlers, either by avoiding use of async void or even by embracing async void, in this article we will explore another option which is Task EventHandlers. Disclaimer: this article was originally written with the perspective that this solution feels close to bullet-proof, but there are important limitations. These limitations are addressed later in the article, and I felt it would still be valuable to explore the space (both positives and negatives). A Companion Video! https://www.youtube.com/watch?v=QVGjpRz0JZU What you DIDN'T know about C# Async EventHandlers The Source of the Problem Normal…
When we discuss async EventHandlers, the first thing that comes to mind for many of us is that it's the only exception that we seem to allow for the dreaded async void setup. When I had written about this before, I was excited that I was exploring a solution that involved actually allowing async void to exist (without wanting to pull the rest of my hair out). For me, this was much more about some clever tricks we can use to overcome async EventHandlers than it was to provide solutions for avoiding the problem entirely. With that said though, there was a lot of traction on the article, which I am very thankful for, and some folks expressed opinions that they'd rather solve async EventHandlers a different way. I thought this was a great point, so I wanted to come…
In C# and .NET, as programmers we have access to an interface that is called IEnumerable (or IEnumerable<T> for the generic version). Using IEnumerable allows us to iterate from a collection or data source by moving one element at a time. It's also important to note that all collection types in C# inherit from IEnumerable so collections you are familiar with like arrays and lists implement IEnumerable. I have been trying to help educate around IEnumerable usage for many years now so this is a renewed effort to help get more junior developers understanding how they work. As a bonus, if you're interested in working with the code that you see in this article you can clone it down from GitHub by visiting this link. A Companion Video https://www.youtube.com/watch?v=RR7Cq0iwNYo Simple IEnumerable Example Let's consider the following code example that will…
In C# 9.0 we received access to a great quality of life type called the record. You can read more about that from Microsoft here. Record types allowed us as dotnet programmers to skip a lot of boiler plate code, thereby saving us time and making code more readable. Wins all around! Before record types, we might have simple data transfer objects (called DTOs) that would look something like the following: public sealed class MyData { public MyData( string value1, int value2) { Value1 = value1; Value2 = value2; } publc string Value1 { get; } publc int Value2 { get; } } And for a simple class with two properties... I think we can all agree that the verbosity here is just over the top. With the record type that we were given access to, we can now write…
You're an intermediate dotnet programmer and you mostly know your way around using Tasks. You sprinkle async and await through your code, and everything is working just as expected. You've heard time and time again that you always want the return types of your asynchronous methods to be a Task (or Task<T>) and that async void is essentially the root of all evil. No sweat. One day you go to wire up an event handler using the syntax myObject.SomeEvent += SomeEventHandler, and your event handler needs to await some asynchronous code. You take all of the right steps and change your method signature to get that beautiful async Task added in, replacing void. But suddenly you get a compile error about your event handler not being compatible. You feel trapped. You're scared. And then you do the unspeakable... You change…
