2025-02 on Funky Si's Blog (Dev)

The Pragmatic Programmer

funkysi1701@gmail.com (funkysi1701) — Mon, 24 Feb 2025 20:00:00 +0000

I have been reading The Pragmatic Programmer and I have to say it is a fantastic book. It is full of great advice and tips for programmers. I highly recommend it to anyone who is a programmer at any level.

Lots of the advice is common sense and things I already do, but there are also lots of things I know in the back of my mind that I should be doing. So reading it has been a great reminder of those things.

Here is the complete list of tips that can be found in the book (I am reading the 20th anniversary edition, so these might be slightly different if you are looking at the original edition):

Care About Your Craft
Think! About Your Work

A Pragmatic Philosophy

You Have Agency
Provide Options, Don’t Make Lame Excuses
Don’t Live with Broken Windows (I blogged about this in 2015)
Be a Catalyst for Change
Remember the Big Picture
Make Quality a Requirements Issue
Invest Regularly in Your Knowledge Portfolio
Critically Analyze What You Read and Hear
English is Just Another Programming Language
It’s Both What You Say and the Way You Say It
Build Documentation In, Don’t Bolt It On

A Pragmatic Approach

Good Design Is Easier to Change Than Bad Design
DRY - Don’t Repeat Yourself
Make It Easy to Reuse
Eliminate Effects Between Unrelated Things
There Are No Final Decisions
Forgo Following Fads
Use Tracer Bullets to Find the Target
Prototype to Learn
Program Close to the Problem Domain
Estimate to Avoid Surprises
Iterate the Schedule with the Code

The Basic Tools

Keep Knowledge in Plain Text
Use the Power of Command Shells
Achieve Editor Fluency
Always Use Version Control
Fix the Problem, Not the Blame
Don’t Panic
Failing Test Before Fixing Code
Read the Damn Error Message
“select” Isn’t Broken
Don’t Assume It - Prove it
Learn a Text Manipulation Language

Pragmatic Paranoia

You Can’t Write Perfect Software
Design with Contracts
Crash Early
Use Assertions to Prevent the Impossible
Finish What You Start
Act Locally
Take Small Steps - Always
Avoid Fortune Telling

Bend, or Break

Decoupled Code is Easy to Change
Tell, Don’t Ask
Don’t Chain Method Calls
Avoid Global Data
If it’s Important Enough to be Global, Wrap It in an API
Programming is About Code, But Programs Are About Data
Don’t Hoard State; Pass It Around
Don’t Pay Inheritance Tax
Prefer Interfaces to Express Polymorphism
Delegate to Services: Has-A Trumps Is-A
Use Mixins to Share Functionality
Parameterize Your App Using External Configuration

Concurrency

Analyze Workflow to Improve Concurrency
Shared State is Incorrect State
Random Failures Are Often Concurrency Issues
Use Actors for Concurrency Without Shared State
Use Blackboards to Coordinate Workflow

While You Are Coding

Listen to Your Inner Lizard
Don’t Program by Coincidence
Estimate the Order of Your Algorithms
Test Your Estimates
Refactor Early, Refactor Often
Testing is Not About Finding Bugs
A Test is the First User of Your Code
Build End-to-End, Not Top-Down or Bottom-Up
Design To Test
Test Your Software, or Your Users Will
Use Property-Based Tests to Validate your Assumptions
Keep it Simple and Minimize Attack Surfaces
Apply Security Patches Quickly
Name well; Rename When Needed

Before the Project

No One Knows Exactly What They Want
Programmers Help People Understand What They Want
Requirements are Learned in a Feedback Loop
Work with a User to Think Like a User
Policy is Metadata
Use a Project Glossary
Don’t Think Outside the Box - Find the Box
Don’t Go into the Code Alone
Agile is Not a Noun; Agile is How You Do Things

Pragmatic Projects

Maintain Small, Stable Teams
Schedule It to Make it Happen
Organize Fully Functional Teams
Do What Works, Not What’s Fashionable
Deliver When Users Need It
Use Version Control to Drive Builds, Tests and Releases
Test Early, Test Often, Test Automatically
Coding Ain’t Done ‘Til All the Tests Run
Use Saboteurs to Test Your Testing
Test State Coverage, Not Code Coverage
Find Bugs Once
Don’t use Manual Procedures
Delight Users, Don’t Just Deliver Code
Sign your Work

Professional Ethics

First, Do No Harm
Don’t Enable Scumbags
It’s Your Life

Understand and handle .NET exceptions

funkysi1701@gmail.com (funkysi1701) — Mon, 17 Feb 2025 20:00:00 +0000

While at NDC London I heard a great talk by Matt Burke about exceptions. I will share some of the points here.

The talk was based in part on the blog post Vexing Exceptions by Eric Lippert.

It defined four types of exceptions:

Fatal Exceptions
Boneheaded Exceptions
Vexing Exceptions
Exogenous Exceptions

Fatal Exceptions

These are exceptions that are thrown when the application is in an unrecoverable state. Examples of these are OutOfMemoryException and StackOverflowException. Don’t try and catch these kind of exceptions, just let the application crash.

Boneheaded Exceptions

These are exceptions that are caused by a bug in the code. These are the easiest to fix, as you just need to fix the bug. Examples of these are NullReferenceException and IndexOutOfRangeException. Boneheaded exceptions are a gift and it is the code telling you, that you have a bug to fix. Do throw these kind of exceptions, when someone messes up. They can be especially useful when someone else is consuming your API, you can throw an exception with a message that tells them what they did wrong.

Vexing Exceptions

These are exceptions that are thrown by the framework, and are hard to avoid. Examples of these are FormatException and InvalidOperationException. These are the hardest to fix, as they are thrown by the framework. You can’t fix the framework, so you have to work around them. You can’t avoid them, so you have to catch them. You can’t ignore them, so you have to handle them. You can’t fix them, so you have to work around them.

One example of this is the int.Parse() method, it will throw a FormatException if the string is not a valid integer. You can’t avoid this, so you have to catch it. Of course a better way to do this is to use int.TryParse() which will return a boolean if the parse was successful.

Exogenous Exceptions

These are exceptions that are thrown by external systems. Examples of these are IOException and SocketException. These are the hardest to fix, as they are thrown by external systems. You can’t fix the external system, so you have to work around them.

A recent example is concurrency problems, if you are processing data in a database and other systems could update it at the same time, you could get a concurrency exception. The data you have in memory might not reflect the real state of that data. You can’t avoid this, so you have to catch it. You can’t ignore it, so you have to handle it.

try
{
 // Do something that could throw an exception
}
catch (Exception ex)
{
 // Log the exception
 Log.Error(ex);
 throw ex; // Bad resets the stack trace
 throw; // Good keeps the stack trace 
}

Also don’t hide Exogenous Exceptions, if you catch an exception and don’t rethrow it, you are hiding the exception from the caller. I have seen code that uses the mediator pattern, it will call a method and not return to the original caller that something went wrong. This is bad, as the original caller needs to know that something went wrong.

If you have enjoyed this article and want to get a monthly email with all my latest articles, please sign up for my newsletter . If you have any questions or comments, please feel free to reach out or leave a comment below.

What is new with C#

funkysi1701@gmail.com (funkysi1701) — Mon, 10 Feb 2025 20:00:00 +0000

I was lucky enough to hear Mads Torgersen (The Lead Designer of the C# language) speak at NDC London about some of the plans the team has for the next version of C#. Many of these new features are in the preview stage, and can be enabled by using the c# preview flag in your csproj file. The C# team welcomes feedback on the different use cases for new feature, especially during these early previews. As this is a preview of new language features, don’t blame me if this all changes before it all ships in Novembers release!

<PropertyGroup>
 <LangVersion>preview</LangVersion>
</PropertyGroup>

Dictionary Expressions

This is an extension of the existing collection expressions that we have had since C# 12, but this time for dictionaries.

The syntax is going to look a bit like

IList<int> foo = [1, 2, 3];
IDictionary<int, string> bar = [1: "one", 2: "two", 3: "three"];

Dictionary Expressions

Simple lambda parameters with modifiers

WithOut w1 = (string s) => s.Length;
WithOut w2 = (s) => s.Length;
WithOut w3 = (string s, out int i) => i = s.Length;
WithOut w4 = (s, out i) => i = s.Length;

Simple lambda parameters with modifiers

Unbound generic types in nameof

var t = typeof(List<>);
var n = nameof(List<>);

Unbound generic types in nameof

Null conditional assignment

var c = C.GetOne();
c.P = "Hello";
c.E += () => { };
c?.P = "Hello";
c?.E += () => { };

Null conditional assignment

Partial events and constructors

partial class Partials
{
 public partial void M(int i);
 public partial string P { get; }
 public partial string this[int i] { get; }
 public partial event Handler? E;
 public partial Partials();
}

Partial events and constructors

Field access in auto properties

class Fields
{
 public string? FirstName { get; set; }
 public string? LastName { get => field; set => field = value?.Trim(); }
}

note the field keyword is a potential breaking change if you have field variables in your code.

Field access in auto properties

This last one revealed a couple of gems of information that I found interesting. Creating a class called var can essentially disable the var keyword, and if you declare a variable called _ it can disable the discard operator. Neither of these things I would want to do in production code, but interesting that the language allows them.

Extensions

We have had extension methods for a while, but what about extension members?

Extension members

public static class Enumerable
{
 // New extension declaration
 extension(IEnumerable source) { ... }

 // Classic extension method
 public static IEnumerable<TResult> Cast<TResult>(this IEnumerable source) { ... }

 // Non-extension member
 public static IEnumerable<int> Range(int start, int count) { ... }
}

This was a fascinating look at what is coming up for C#, and it will be interesting to see how these new ways of writing code will get adopted.

Volunteering at NDC London

funkysi1701@gmail.com (funkysi1701) — Mon, 03 Feb 2025 20:00:00 +0000

I have just come home from volunteering at NDC London. It was a great experience and I learned a lot. I met some great people and had a lot of fun. I can’t wait to go back next year.

You may have heard of NDC London before. It is a conference for software developers. It is held in London every year and attracts people from all over the world. The conference covers a wide range of topics, with a strong focus on .NET. I have heard about the conference for years and always wanted to go, but with ticket prices in the thousands, it was out of reach for me.

Late last year, I saw a contact on social media mention that volunteering at NDC was a good way to go to the conference for free. I had heard that this was an option before, but hadn’t acted upon it. So I sent a quick email to the conference organizers. I didn’t expect I would get on the team, but they emailed back and said I was on the team, and asked what was my t-shirt size. I was so excited!

The event is held at the Queen Elizabeth II Centre , which is a great venue, right next to Big Ben and Westminster Abbey. The conference is spread over a whole week, with 2 days of workshops and 3 days of talks. Volunteers are only needed for the 3 days of talks, however, there was an intro meeting the day before.

As a volunteer, you don’t get paid, so I needed to arrange my own transport to London and accommodation. It being London, I knew the tube network was a quick and easy way to get around, so I could search for a reasonably priced hotel that was near the venue.

The intro meeting was on Tuesday evening, at 5.30 pm. I arrived a bit early and unfortunately, I wasn’t very clear about why I was there so I was told to wait and the meetup would go upstairs soon. The London .NET user group was having a session at 5 pm with Mads Torgersen (the C# language designer), but luckily I double-checked and got to wait with the right people. However, this was not a bad thing, as I got to see some of the .NET team walk past, like Steve Sanderson and of course Mads Torgersen who was going to the meetup.

Once the intro meeting started, we unboxed the hoodies that every attendee was given. These ranged in size from XS to XXXL, we also learned how the registration process worked. Scan a QR code, print off the ticket, stick it to the lanyard, and issue it to the attendee. I also found out that there was a decent Yorkshire contingent, some I had met from York and Leeds user groups. We had a tour of the venue, the conference was on floors 3, 4, and 5. The top floor had a great view of Big Ben and Westminster Abbey. We were also issued our own T-shirt and hoodies, which were purple and said NDC Crew on them along with our lanyard passes.

It was an early morning, we needed to be at the venue for 7 am, ready to welcome 900+ people to the conference when the doors opened at 8 am. I helped man the hoodies, handing out XXL to any attendees who wanted them. There was a steady stream of people registering, however, I didn’t feel overwhelmed. By the time we had finished at registration, the keynote with Scott Hanselman was about halfway through, so I went to get a coffee and some breakfast and had a look at the schedule for the day. I was assigned to help out with the afternoon sessions so I was free to attend any sessions I liked in the morning.

For my afternoon duties, I needed to report back when the speaker had arrived and count up the number of green/amber/red cards for the session. At NDC feedback for the different speakers is submitted by the attendees by putting cards of different colours in a box. Green for good, amber for ok, red for bad. Throughout the different talks I attended there was always a good proportion of green cards, indicating the high quality of the speakers at NDC.

Wearing a purple NDC Crew hoodie, gave me a certain amount of confidence, I walked among many of the sponsors and chatted to a few. Elastic Search had a stall, and I mentioned my recent experience at work with them. At some conferences, I can feel a bit out of place, but at NDC being a volunteer, I had an automatic group of friends to chat to, the other volunteers, and this also helped me speak with one or two of the speakers. I enjoyed saying hello to Richard Campbell, who I had listened to on the .Net Rocks and RunAs Radio podcasts for years. I told him he had sent me a mug, and he mentioned it was a collector’s item now.

At the end of the first day, I was invited to the speaker dinner, which was a great experience. I got to chat with some of the other volunteers. I had a great time and it was free food and drink so I can’t complain.

While I was volunteering, I was often hanging out with the other volunteers. We had a great time, and I made some new friends. We had a lot of fun, and I learned a lot, which I hope to blog about soon. I can’t wait to go back next year.