DEV Community: Mark Clearwater

We are all 10x engineers, but I don't think it means what you think it means

Mark Clearwater — Mon, 15 Jul 2019 21:50:55 +0000

If your reading this blog, and used twitter in the past few days, you have probably already seen this tweet, or some of the replies coming through from the community:

10x engineers

Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.

OK, here is a tough question.

How do you spot a 10x engineer?

— Shekhar Kirani (@skirani) July 11, 2019

As a developer who tries to be good at their job, I have thoughts on this. As a Human, I like to be heard. (Note that being heard is not the same thing as being agreed with, or being right.) So here I am giving my opinion on this idea of a 10x developer, and specifically these "10 signs" put up online.

I like the idea that there are no 10x people, instead, you can strive to produce 10x teams.

1. Meetings

A lot of people don't like meetings. But unfortunately, communication is a big part of effective teams and businesses. While it is true that some people love meetings, and some meetings don't hold productivity, the key here is communication. If you can find an effective means of communication within a team that works, that is most important. Having a team full of people that don't have meetings doesn't make a 10x team. If meetings are causing you or your team problems, it is work looking at other strategies for effective communication. There are alternatives out there.

2. Office Hours

"Nine to Five" is such an old fashioned idea these days. Not only do some countries have alternative ideas like 4 day weeks, long lunch hours, "flexitime", but more and more business work across locations and across timezones. We are asking people to work outside these hours for various reasons already, so why not some give and take here?

Most people would love flexible work hours. It turns out that if people can work around their own schedule, they put their best work forward when they are present. I would much rather have someone contribute 100% at 9 pm at night because their kids are in bed and they can concentrate rather than pay them to sit at their desk for several hours texting and calling their family. Just a thought.

We are so fortunate that in our industry is so capable and adjustable to different working hours that it is a shame not to support this. It is not that "10x developers are the people who like this", it is actually that most employees want this, and it can be done.

3. Screen colour and worn keyboards

If I saw a sports star on the field/pitch/court wearing badly worn shoes, I wouldn't think "This is a superstar", I would probably think "he isn't paid enough".

Why are you letting your developers use worn-out equipment? Buying the required hardware and software is such an important thing, just do it! In all seriousness, though, giving staff the right tools to get their job done is always a good idea.

There is an interesting dichotomy with custom technical tools as well. If you have one developer that goes against the grain of the team with customisation, then it both makes it harder for them to use other machines (e.g. during pairing/mobbing) and for others to use theirs. There is some efficiency to using the out of the box defaults too. You can get up and running faster, and waste less time doing customisations every time you refresh your machine or change jobs and get new hardware.

Also, if you have to have everything customised your own way, you won't be able to acclimatise to new situations, new tools, new teams. Not someone you want to add to your team.

4. Good memory

One my big comparisons between my generation and the one before me (that is the one with the access to Google, but not access to iPads) was that at school we were no longer taught to memorise and recall information. Instead, we were taught, and learned, the importance of finding and referencing information. There is too much information for us all to hold in our heads. knowing where to look and what to look for is far more important that memorised information for a technology that will be obsolete in 3 years (if you are lucky), let alone memorising a dozen of them over time.

Yes, it is great to get people who know the domain really well, and for some people, it really is a skill. But people can't know what they haven't seen yet, and new hires always start as a blank slate. Not to mention tomorrow will bring a new set of libraries, applications and services that need to be learned and understood.

Scott Hanselman talks of the experience-groundhog-day scenario.

Do you have 10 years’ experience, or the same year 10 times? https://t.co/LhIeWiWl3H

— Scott Hanselman (@shanselman) May 29, 2018

5. Full Stack

Don't you love buzz words? FullStack. A full-stack would be from the HTML/CSS/js to the backend code, to the database. But it is also understanding how the TCP/HTTP layer works with packets and routing. How does your platform infrastructure run, do you manage and patch the servers? Database backups and data security, not to mention how the hardware scales, can you write the assembly to work with arm processors too?

Jack of all trades, master of none. That is a saying that acknowledges you are spread too thin. You can't be an expert in everything, so instead, you can hire an expert in each thing. Yes, you want everyone to be a generalist, but make sure you have coverage with all of the specialists, too.

I can't say I've met too many people who can design and build an amazing user experience, and also optimise a large scale database, and run a datacentre. Oh and also works well with others...

6. Wait, WAT?

This one I just have to quote it in two parts:

10x engineers can convert "thought" into "code" in their mind and write it in an iterative fashion.

Just for a second, imagine with me, that you could replace the words "10x engineer" with "a developer". Crazy idea, but it might actually work.

Given a product feature, they can write that entire feature in one or two sittings of 4 to 6 hours with a caffeinated drink without distraction.

We all have good days where we fire on all cylinders. Or a task or feature fits into just the right hole in a system. Cherish the days when it happens, but realise its more about the stars aligning and less about the ability of your developer. We are all capable of this. But the rest of the time it's just a Monday.

7. Good Memory. Part Deux

We talked about this. Enough said.

8. Learning

This is another one of those things with a dichotomy. If you are always learning something new, you never get to master anything. There is a benefit to having people who are masters, and people who can learn, and people who can teach and share. You need balance both as a developer and person, but also in and within a team. If you don't have this yet, look at hiring the capabilty, but don't use it to rule in or out talented people.

9. Terrible leaders

Yes. I think exactly what you want to do is hire someone who cannot teach how the system works to new staff. That will help you grow. No, not really. The team is only as strong as its weakest point. And the ability to both cover for, and teach and grow newer talent is key to growth and success.

Also, while it is true that some people will be amazing on your team, but will interview poorly, I can't say there is a direct reverse correlation here, either. Sorry.

10.

10x engineers rarely job hunt or move out of the company. They move out because you make their life miserable with the process, meetings, training, and other non-value-added activities. If you come across them, hold on to them. Celebrate them.

So close. This is the first point I almost agree with. Just go ahead and replace "10x engineers" again with "developers", Or even just "employees" will do.

0.1x developers

While there are seeds in here that make for an interesting debate, they have nothing to with "10" or "X". The best summary of the whole situation is this: The scale is off. I think the truth of the matter is that there are developers who might contribute to failings in a team (and some warning signs appear above, under the wrong inversion, though). We can call them the 0.1x developers. They are the ones to truly watch out for.

As founders and employers, you will want to be doing all the right things to attract and keep good talent, and that is more important than going after a mythical creature known as the 10x developer.

What someone needs to do is follow the footsteps of Dylan Beattie's Rockstar programming language and make a language or piece of hardware board and call it "10x". Then we can all be Rockstar Programmers and 10x Engineers.

Snuffleupagus-Oriented Programming

Mark Clearwater — Mon, 08 Jul 2019 18:00:00 +0000

An impromptu introduction to Snuffleupagus-Oriented Programming (SOP): https://t.co/jPkjPRgqQr

— Casey Muratori (@cmuratori) July 21, 2015

Sometimes naming something is the best way to start talking about a topic that lots of people do but don't realise or haven't pulled together as a concept. This is one of those ideas that finally has a good (?) name.

How do you build out a new API? Here we are meaning programming contracts effectively. You can hack away until you have something functional, and then start consuming it. Better yet, build it out as code to do a job and then ship it to someone else to try and use.

Most developers get to a point where they see the value in having contract design up front across team boundaries, layer boundaries, reusable components, HTTP/Soap boundaries etc. An evolved design for these will never be as good as an intentional one. And on the flip side, we have all used clunky library APIs in various languages, BCL or otherwise.

What is Mr Snuffleupagus

The name comes from Sesame Street. Muppets basically. Big Bird and Bert and Ernie, Elmo etc. There was a storyline decades ago where Big Bird kept seeing Mr Snuffleupagus and talking about him, but no one else ever saw him. They concluded it was an imaginary creature for a long time. In the show, it was very ambiguous what the truth was. Eventually, they actually saw the Snuffleupagus too and concluded it wasn't imaginary after all. More here.

Enter SOP

The ideas from this story match an approach to building your API.

First, we are going to imagine that what we want to use exists. Then we are going to write code against the API, crafting our usage case, without implementing anything. Once we are happy that our API is usable, we implement it and make it actually exist, make it real. There may be a few tweaks once the realities and limitations of the implementation are taken into account, but the idea is to try and keep it as usable as the original usage cases as possible, usability intact.

via GIFER

TDD

This is a great candidate approach to work with TDD as well, just with more implementation code along the way to produce passing tests. Like Mr Snuffleupagus, this implementation code is imaginary until you have enough test cases to make it real, and refactor.

Thanks

Go forth and start sharing SOP, Snuffleupagus-Oriented Programming. Imagine, Build Usage, Make it Real. Thanks Casey Muratori for coining the term and making it stick. See more of his programming on HandMade Hero (YouTube), and his company Molly Rocket for games and more.

Looking Back on C# 7: Pattern matching

Mark Clearwater — Mon, 01 Jul 2019 18:00:00 +0000

With C# 8 on our doorstep, I figure it is a good time to reflect on recent additions to the language that have come before. There are some great improvements you may have missed, some that I really enjoy using, and some I consider have reached canonical usage status that I think are all worth some reflection.

Pattern matching is a powerful feature that has been unlocked against various language constructs in C#. The idea is to take existing features like case from switches and is and extract their capabilities into a "pattern matching" concept over types and values. This can then be applied back to these language features, and other places in the future.

Before the new concept of patterns, case accepted a constant as an argument, and is would accept a type.

// Check the type of the variable "is assignable to" Shape
if(widget is Shape)
{
    switch ((widget as Shape).Type)
    {
        // When value matches the constant "Square"
        case "Square":
            // ...
            break;
        default:
            break;
    }
}

With the introduction of C# 7.0, both of these language features have been enhanced to use the new Pattern Matching syntax. This is a backwards-compatible change, meaning that the pattern type can be a const or a type. As well as these existing cases, it also includes when clauses and var patterns as well.

is Expression

Originally, is was able to check a type. This could create more readable code but often left casting or as operator usage in the aftermath.

if (widget is Shape)
{
    var myShape = widget as Shape;
    // var myShape = (Shape)widget;
}

This has been improved by the pattern matching. First, we have constant checking:

if (widget.Type is null)
{
    // ...
}

if (widget.Type is "FOO")
{
    // ...
}

As well as this, the Type checking Pattern now includes support to create a scoped variable of the correct type, similar to the new out parameter functionality. This language feature is collectively known as "expression variables".

if (widget is Shape shape)
{
    // ... use `shape`
}

Switch Statement

A switch used to only match on constants, but with the new pattern matching, we can do so much more.

void SwitchIt(object value)
{
    var result = 0;
    switch (value)
    {
        // We can still switch on constants, even when the types don't match
        case 0:
            break;
        // We can switch on type, and even create a scoped variable (like with `is`)
        case IEnumerable<int> childSequence:
        {
            foreach(var item in childSequence)
                result += (item > 0) ? item : 0;
            break;
        }
        // using `when`, we can do range or bounds checking
        case int n when n > 0:
            result += n;
            break;
        // We can constant check against null
        case null:
            throw new NullReferenceException("Null found in sequence");
        default:
            throw new InvalidOperationException("Unrecognized type");
    }

    return result;
}

There is another new pattern that is useful with switch, which is the var pattern. The "var pattern" is similar to the type pattern, except that it always matches, but creates a variable with the assigned value.

switch(shape)
{
    case Circle c:
        WriteLine($"circle with radius {c.Radius}");
        break;
    case Rectangle s when (s.Length == s.Height):
        WriteLine($"{s.Length} x {s.Height} square");
        break;
    case Rectangle r:
        WriteLine($"{r.Length} x {r.Height} rectangle");
        break;
    case var s:
        // Always matches (similar to default) but gives access to the value as `s`
        WriteLine($"This is some kind of {s.Name} shape");
        break;
}

It is worth pointing out that the order of your case arguments now matters. while not a logical breaking change, since it never mattered what order constants where declared, it would always match the right answer, this is a conceptual change you need to be aware of. Mixing and matching patterns in a switch mean that the order does matter, and the first pattern that matches will get executed. To repeat, when all cases are constants this wouldn't make any difference to the outcome but more advanced checks will.

In C# 7.1, the patterns were extended to work correctly with generic variables as well. In C# 7.0, you could use these type patterns as expected by first casting the T foo value to an Object (which could cause Boxing) and then the type checking would all work. In C# 7.1, this cast is no longer necessary, and also avoids any boxing and unboxing along the way. The docs go over this is more detail with an example comparing the two implementations, as there are a few subtle differences, especially around null/default cases.

Pattern Matching coming soon

This feature is an interesting one in the sense that it is both newer and probably under-used and less known. You can program away happily in C# never needing to use it and not coming across it.

But with C# 8, there is a bunch of new features that will be using this existing pattern matching coming, so you might want to get on board with this in preparation, because soon you will need to understand code using it, and probably see a lot more of it around.

Bring on the Switch Expression!

Looking Back on C#: async and await

Mark Clearwater — Mon, 24 Jun 2019 18:00:00 +0000

Multithreaded programming has always been a difficult thing to get your head around, and there are many pitfalls easily stumbled into. To help combat this, Microsoft gave us async/await in C#.

Async/Await is a language feature that has been around since Visual Studio 2012 and C# 5 and hides a bunch of the boilerplate state machine code required to safely park a logical thread of execution while it waits for some work to complete or to respond from another thread, IO, or network device. This allows code to be more logically procedural and linear, therefore easier to read and comprehend.

Since it first came out there has been a raft of improvements across different versions of C#.

The basics

The foundation of how it all works rests on the shoulders of a Library, the Task Parallel Library, or TPL. Tasks have been around since 2010 and were part of the .Net 4 Framework. Similar to what Promises provide in javascript, this library allowed a logical chain of execution across waiting for blocking or longrunning execution while releasing the UI thread from being blocked. This was the introduction of TaskFactory and Task, in a fairly similar form to what we have today. This was a huge improvement from the days of callback chaining because it reduced heavy nesting of lambdas into more of a linear pipeline and a clear place for error handling to take place.

When C# 5 introduced async/await as a first-class language feature, it was able to leverage the library and extend on it to give us more readable code. It even handled Exceptions by throwing them in the place where await appeared, making try/catch blocks useful in asynchronous code.

What does async/await look like in C# 5?

// A classic synchronous method
public string MakeAWebRequest(Uri uri)
{
    // WebClient has synchronous methods, but it is recommended to use HttpClient for newer apps
    var client = new WebClient();
    return client.DownloadString(uri);
}

// It's async younger brother
public async Task<string> MakeAWebRequestAsync(Uri uri)
{
    // I use WebClient again for better comparing. Use HttpClient!
    var client = new WebClient();
    return await client.DownloadStringAsync(uri);
}

There are two distinctive features in this comparison. The return type is wrapped in a Task<T>, and there is a keyword async on the method signature with await beside method calls that return Task<T> results. Otherwise, the linear execution flow is largely unchanged.

You can easily use the return type without the keywords. In this case, the code works and operates as normal, passing object references around without any async state. The result object captures the state required for the caller to do the asynchronous work in the future, or respond to its completion. However, if you do use async and await, then you should always return either Task (where usually returns void) or Task<T> (where usually returns T). (In my opinion, there are no reasons left to ever do async without Task - there used to be but not anymore.)

Now we have that out of the way, let's move forward to C# 6 and beyond!

Async and Exceptions

Exception handling was a big part of this feature on day one. You could simply wrap your async calls in a try{}catch{} and it would work as you would expect it to. The task you are awaiting throws an Exception, your catch triggers.

But initially, this did not work inside the catch or finally blocks in any expected way. In fact, it caused a compiler error. In C# 6 await in catch/finally blocks were given proper compiler support to do the right thing.

Using the example from The new language feature docs directly:

Resource res = null;
try
{
    res = await Resource.OpenAsync(…); // You could do this.
    …
} 
catch(ResourceException e)
{
    await Resource.LogAsync(res, e); // Now you can do this …
}
finally
{
    if (res != null) await res.CloseAsync(); // … and this.
}

Async and Console Apps

The language version was C# 7. We had async everywhere, and the NetStandards and Frameworks were full of async API calls and interfaces. It was a contagious thing, and you really had to jump through hoops to try to call a red function from a blue one.

And then there was main. That pesky little entry point into your application. The one the compiler generates for you that kicks off all of the application execution. The one that had to call into your top-most async method to RunAsync. And it had to be public static void Main(string[] args) or public static int Main(). That is not an async method.

Luckily, with the first ever minor language update, C# 7.1, we were given the mighty and powerful async main!

// You can finaly use Task<int>!
public static async Task<int> Main()
{
...
}

// Also available in no return value flavour!
public static async Task Main()
{
...
}

Async and Tests

We have a tonne of async methods in our system. But we should also be testing that code. And our testing frameworks were synchronous.

Luckily our testing frameworks have finally caught up, and with XUnit we can write tests that return Task and are async, and we also have theIAsyncLifetime` interface.

`
// This is what we had to do to test async
public class MyTestCase
{
private readonly MyClass _systemUnderTest;

public MyTestCase()
{
    _systemUnderTest = MyClass();

    Task.Run(async () => await _systemUnderTest.Init()).GetAwaiter().GetResult();
}

public void CanRunSuccessfully()
{

    var result = Task.Run(async () => await _systemUnderTest.Run()).GetAwaiter().GetResult();

    Assert.True(result);
}

}

Using Task.Run and GetAwaiter or other synchronising methods can be very error-prone, and prone to deadlocks. Avoiding these is the best approach always (though still not always avoidable).

`
The best way to tet with async
public class MyTestCase : IAsyncLifetime
{
private readonly MyClass _systemUnderTest;

public MyTestCase()
{
    _systemUnderTest = MyClass();
}

public async Task InitializeAsync()
{
    await _systemUnderTest.Init();
}

public Task DisposeAsync()
{
    return Task.CompletedTask;
}

public async Task CanRunSuccessfully()
{

    var result = await _systemUnderTest.Run();

    Assert.True(result);
}

}

I'm not sure if other test runners are able to handle async as well as XUnit does, so I always just use XUnit.

ValueTask

The original implementation of the async/await language feature was strongly tied to the Task and `Task types.

In C# 7, the language feature was enhanced, similar to other features, to use a pattern based on method signatures (like the Add for the initialiser syntax). Specifically, the GetAwaiter method must be available on the type used with the await keyword.

Along with this change was the introduction of a new type to leverage this pattern, ValueTask. A ValueTask is a value type (struct) that will be stack-allocated and copied by value. If your method uses caching, and most of the time returns a simple value instead of an awaited execution, the ValueTask may be more efficient than the Task type.

This is because the overheads of Heap-allocation of the reference type Task can have an impact on performance. If you detect this as an issue, you can use the new ValueTask instead. This will be a stack-allocated value type containing the response value and copied around.

Guidance for this: if you mostly return a value, but occasionally call an actual asynchronous IO execution, ValueTask will probably add value (e.g. heavy result caching). If you actually await most of the time, Task should be fine. As usual, measure and test before making the change arbitrarily.

Conclusion

Async programming is becoming the canonical way of building apps with IO in most languages. And in practice, most of the apps I write are IO-bound apps. C# and dotnet make this simple with async/await and the language keeps improving our experience using this successfully. This is a must-use feature that is unavoidable, but knowing the limitations and extensions available to use it well is still very important to do. Use it, but make sure you know enough about how it works to use it well.

Looking Back on C# 7: refs enhancements

Mark Clearwater — Mon, 17 Jun 2019 18:00:00 +0000

We talked about the out variables in the previous post in the series, but there are a few other enhancements related to ref as well.

Hopefully, the concepts of values, pointers, stacks and heaps make sense to you at a conceptual level. These are crucial concepts to using and understanding ref and out.

As a quick recap, stack memory is local to a function and the function call stack. This memory is semantically "pushed" to for each method call, and "popped" from on each return (the call stack, stack overflow etc). The heap is a shared memory space where objects are allocated and stored, which is acted on by the Garbage Collector.

Values are mostly stack-allocated. They are copied around so that setting a value variable does not affect any other variable. Primitive types and structs are Value types. Reference types are the classes in C#. Classes are always stored on the heap, and all variables of class types are pointers or references. Assigning a reference to a new variable will point to the same value on the heap. Changing a field value on a reference type will be reflected in both variables. (Boxing values onto the heap is another thing, too.)

We already have out that allows the caller to declare a variable on the current stack that it passes by address (pointer, reference, or ref) that the method is contracted to set for you. This essentially gives us some of the power of reference types from a stack-allocated value. When we use ref, we gain all of the power of passing by reference that we have from heap allocated class types. We are essentially saying that the caller can use the existing value of the reference, and also set a new value to the stack variable if it wants to as well. Basically, all the restrictions that out imposes are taken off. A ref may not just be a stack variable, but could also be a field on a class that you want to access directly by reference, instead of having to constantly dereference it.

Pass by ref has been in C# since the beginning, but like the out parameters, only works in method signatures. However, from the beginning, you could never declare a ref variable.

In C# 7, ref has been extended to work with return types, and with variables. You can return a value by reference. And so that it the returned result can be assigned to something in a useful way, we also now have ref variable typing. Like most C# language features, there is safety built in.

You must add the ref keyword to the method signature and to all return statements in a method.
A ref return may be assigned to a value variable (by copy) or a ref variable.
You can't assign a standard method return value to a ref local variable.
You can't return a ref to a variable whose lifetime doesn't extend beyond the execution of the method.

These rules ensure the safety of your code and ensure readability, that it is clear about what is happening.

I'm going to blatantly steal the Microsoft examples for this because I don't want to invent an example and get it wrong.

// We declare the method as returning by reference (rather than copy)
public ref int Find(int number, int[] numbers)
{
    for (int i = 0; i < numbers.Length; i++)
    {
        if (numbers[i] == number)
        {
            // All returns must use the `ref` keyword
            return ref numbers[i]; // return the storage location, not the value
        }
    }
    // We can still throw an exception if necessary
    throw new IndexOutOfRangeException($"{nameof(number)} not found");
}

// arrays are already allocated to the heap and passed by reference rather than by value
// (see the `stackalloc` keyword for stack allocating arrays, though)
int[] array = { 1, 15, -39, 0, 7, 14, -12 };

// We have to use `ref` to call the method
// We choose to declare `place` as a reference
ref int place = ref Find(7, array); // aliases 7's place in the array
place = 9; // replaces 7 with 9 in the array
WriteLine(array[4]); // prints 9

In the above example, we could have chosen to declare place without the ref keyword and the value returned would be copied instead. However, in this case, the assignment of place = 9; would be overriding the local copy, and not modifying the original array.

Why would you use these pass by reference additions? Huge performance enhancements can be achieved by avoiding stack and heap copying or dereferencing of values in certain algorithms. Performance is the name of the game here.

In C# 7.2, the conditional operator (isTrue ? x : y syntax) can now evaluate to a reference result when both operands (x and y above) are also references.

ref var r = ref (arr != null ? ref arr[0] : ref otherArr[0]);

In 7.2 we also got ref readonly, which allows returned references to disallow modification enforced by the compiler. This may save time constantly dereferencing a child field in a scenario that you need to get the latest value, for instance in a loop. Again, performance is the target use-case.

The first version of ref variables was immutable only. Whatever you declared them to point to was what they always referred to for their lifetime. In C# 7.3, they were updated so you can reuse a variable to point to a different reference instead.

To complement the safety of the out restrictions compared to ref we also get the in keyword.

Declaring a method parameter with in essentially makes it a read-only reference. the method is not allowed to modify the value passed in but gets all the benefits of being passed by reference rather than by value (copied). The in keyword will make the compiler ensure that the method is not allowed to modify the original passed in value. If necessary it will create a defensive shadow-copy to ensure that is true.

This is well paired with another new feature, readonly struct. Declaring a struct as read-only means the compiler will ensure you are indeed read-only. (It will disallow public int Foo { get; private set; } for example.) You can use the in keyword for any methods that you want to take a ref to one of these structs again to ensure clarity when reading the code, but also enforced by the compiler.

I mentioned the defensive shadow copy above. The language and runtime do not guarantee that the internal implementation detail of a Property or Method is non-mutable from the contracts, so the compiler will get defensive, and make copies before calling anything that might cause a mutation. This way, the language guarantees the expectations of passing a read-only reference, but maybe doesn't match performance expectations in the process. As a developer, by making the type a readonly struct instead, the compiler can rely on the guarantees and won't make any copies. The struct won't compile if it mutates any of its internal state, so we have stronger guarantees at compile-time and run-time.

These features are certainly power features, and when you need them they will be useful. But like most advanced features, you may be sacrificing readability for performance and optimisation. Use sparingly, but maybe measure first and then sprinkle in and measure again.

Looking Back on C# 7: Out variables

Mark Clearwater — Mon, 10 Jun 2019 18:00:00 +0000

What are out parameters?

Sometimes you want a method to pass back a value by reference. In C and C++ this is done by passing the address in as an argument. In C#, we use the out keyword.

public bool HasCount(string str, out int length)
{
    length = 0;
    if (str.Length > 0)
    {
        length = str.Length;
        return true;
    }
}

string myString = "A String";
int length;
if (HasCount(myString, out length))
{
    // Do some stuff here.
}

A method must initialise the out parameter value, but the caller doesn't have to initialise it first. Callers must use the out keyword when calling a method with an out parameter. This helps with readability making it unambiguous how it works.

More details of this for those unfamiliar with the concept can be found here.

In the libraries, there are a few methods that use this, for instance Int32.TryParse.

int number;
if (Int32.TryParse(numberAsString, out number))
{
    // use `number` as an integer value. 
}

It also comes in useful when you are building C-style interops. But not something you see very much these days.

New out variables

This syntax always felt a bit clunky. Modern APIs would suggest using a return value over an out parameter, and the early use cases tended to be either cross-compatibility with C libraries or parse scenarios. Primarily it was discouraged for readability reasons, though there are benefits from using it in certain places.

However, with C# 7, a new syntax was introduced, allowing inline declaration of out parameters.

if (Int32.TryParse(numberAsString, out int number))
{
    // use `number` as an integer value. 
}

You can now declare the parameter inline, without needing the empty declaration line that was essentially wasting line-count. The other benefit is you can now use var instead of an explicit type.

if (Int32.TryParse(numberAsString, out var number))
{
    // use `number` as an integer value. 
}

In C# 7.3, this out variable syntax was extended to include field initializers, property initializers, constructor initializers, and query clauses. Basically, you have the power to use this everywhere that you can use out parameters.

With the new changes, readability has hugely increased, the risk of using the value before initialisation has been removed, and it is probably something worth encouraging using again in those methods that could benefit with having out parameters for clean APIs, and performance.

A small but simple improvement to the language that I would replace in every place you use out parameters.

Looking Back on C# 7: Local functions

Mark Clearwater — Mon, 03 Jun 2019 22:00:00 +0000

Lambdas - a recap

All the way back in C# 3 we were given lambdas. These are anonymous functions that can be passed around as what are essentially function pointers.

"Anonymous" refers to the fact that the function has no name, and is not tied to an actual class or instance. The term comes from functional programming.

In terms of implementation details, there are two categories of lambdas, those which stand alone and are pure functions, and those that have a captured scope, known as a closure. Closure, again, is a functional programming term. We capture variables from the scope of the parent and encapsulate them into this anonymous function instance.

Pure functions can easily be refactored into a public static function in a static class very easily, and the compilation is very similar.


static Action<int> GetRandomValueFunction()
{
    Console.WriteLine("Use static value for counter: {0}", counter);
    return () => 5;
}

// These two methods are the same as the above
static Action<int> GetRandomValueFunction()
{
    Console.WriteLine("Use static value for counter: {0}", counter);
    return StaticValueFunction;
}

static int StaticValueFunction()
{
    return 5;
}

There is no simple construct equivalent for closures. Hopefully, by example, we can see how these transform into simple static methods anyway. (In an example stolen from SO)

 static Action CreateShowAndIncrementAction()
{
    Random rng = new Random();
    int counter = rng.Next(10);
    Console.WriteLine("Initial value for counter: {0}", counter);
    return () =>
    {
        Console.WriteLine(counter);
        counter++;
    };
}

Given the above C# code, the compiled code will more closely resemble the below:


static Action CreateShowAndIncrementAction()
{
    ActionHelper helper = new ActionHelper();        
    Random rng = new Random();
    helper.counter = rng.Next(10);
    Console.WriteLine("Initial value for counter: {0}", helper.counter);

    // 
    return helper.DoAction;
}

class ActionHelper
{
    public int counter;

    public void DoAction()
    {
        Console.WriteLine(counter);
        counter++;
    }
}

Because the compiler generates these, it also controls access and visibility, so that you cannot actually access it in this way from your code directly. But it does all this automatically for you, and with fewer lines of code to achieve the same logical execution. It is also clearer from the lambda version that the calling method is the owner of the function, and no one else can or should share it.

Clearly, lambdas reduce our lines of code and are superior.

working with lambdas

Sometimes, though, your lambdas get complicated. When you have big complicated lambdas inside LINQ pipelines, it gets messy fast.

public List<Widget> GetWidgetsByPlumbob(string plumb, int restrictionNumber)
{
    var restriction = _store.GetRestriction(restrictionNumber);


    // This `where` clause is only going to get more complicated from here.
    _store
        .GetWidgets()
        .Where(w => (w.PlumbBob.StartsWith(plumbob) || w.PlumbBob.EndsWith(plumbob)) && w.Restriction == restriction)
        .Select(Map)
        .ToList();
}

We have a few options prior to C# 7:

public List<Widget> GetWidgetsByPlumbob(string plumb, int restrictionNumber)
{
    var restriction = _store.GetRestriction(restrictionNumber);

    _store
        .GetWidgets()
        .Where(w => Filter(w, plumb, restriction))
        .Select(Map)
        .ToList();
}

private bool Filter(Widget widget, string plumb, Restriction restriction)
{
    return (w.PlumbBob.StartsWith(plumbob) || w.PlumbBob.EndsWith(plumbob)) && w.Restriction > restriction;
}

There are a couple of problems with this. We are now passing all the parameters through to the nested function. This is fine, but from a maintenance point of view, we might add more parameters and we now end up maintaining two signatures every time we change.

Also, we open up for another function to start using the "sharable" filter function. Now we would be coupled to that new function. We can't change our own filter without affecting that other new function, and that adds brittle fragility. Sometimes duplicating logic that has different reasons to change is worth the duplication, but the architecture of this code does not guard against this.

Another example is to pull the lambda into a variable:

public List<Widget> GetWidgetsByPlumbob(string plumb, int restrictionNumber)
{
    var restriction = _store.GetRestriction(restrictionNumber);

    var filter = w => (w.PlumbBob.StartsWith(plumbob) || w.PlumbBob.EndsWith(plumbob)) && w.Restriction == restriction);

    _store
        .GetWidgets()
        .Where(filter)
        .Select(Map)
        .ToList();
}

Looking at the example, it adds some simplification. Because like the original example this lambda is a closure, the lambda can match the expected signature of the Where LINQ Extension.

However, sometimes this approach causes issues with type interpolation. That is, if you pull out into a variable, often you can't use var or need to add explicit type casting to help the compiler out, or it will not compile.

I don't think we have actually helped with the readability as much as we would like. It may not be obvious on the first pass of reading the function that this is a lambda, not a statement. This is also a simple example, and they can get more complex fast.

Put functions inside your functions!

With C# 7, we can now use a nested function. This gives us the benefits of not polluting the namespace of the class, while also making it more readable. It also makes it clearer that the function is owned by the caller as the only consumer.

public List<Widget> GetWidgetsByPlumbob(string plumb, int restrictionNumber)
{
    var restriction = _store.GetRestriction(restrictionNumber);

    bool Filter(Widget widget)
    {
        return (w.PlumbBob.StartsWith(plumb) || w.PlumbBob.EndsWith(plumb)) && w.Restriction > restriction;
    }

    _store
        .GetWidgets()
        .Where(Filter)
        .Select(Map)
        .ToList();
}

Our compiler now ensures no one else can use this function. It is only callable from this method and gives the reader the knowledge that this is a specific implementation detail for this function only and not a shared common piece of logic. (Encapsulation.)

In this example it also still allows us to use the simplified Where call.

The best example of where this is really useful is recursion.

Often a recursive algorithm has a bootstrap function, that then calls the recursive part. Let's print a tree of items with indentations.

public static void PrintLines(TextWriter out, Tree items)
{
    out.WriteLine(items.Title);
    foreach(var node in items.Children)
    {
        Print(out, node, "");
    }
}

private void Print(TextWriter out, TreeNode node, string indent)
{
    out.WriteLine("{0}{1}", indent, items.Title);
    if(node.HasChildren)
    {
        foreach(var node in items.Children)
        {
            Print(out, node indent + " ");
        }
    }
}

For simplicity you can now write this:

public static void PrintLines(TextWriter out, Tree items)
{
    void Print(TreeNode node, string indent)
    {
        out.WriteLine("{0}{1}", indent, items.Title);
        if(node.HasChildren)
        {
            foreach(var node in items.Children)
            {
                Print(out, node indent + " ");
            }
        }
    }

    out.WriteLine(items.Title);
    foreach(var node in items.Children)
    {
        Print(node, "");
    }
}

This example may not reduce lines of code by much, but the cognitive load of the encapsulation can be hugely beneficial when in a class with more service methods as well.

Summary

The cliché "another tool in the toolbelt" comes to mind but this is certainly that, and sprinkled through code strategically can really help with readability and maintainability. Not a "use often" but certainly something I can and have used in my dotnet apps.

µCon 2019 - Day 3

Mark Clearwater — Fri, 31 May 2019 22:00:00 +0000

Good morning day 3. So much to absorb already from Day 1 and 2 but it isn't over yet.

This morning's Keynote "Crossing the River by Feeling the Stones" from Simon Wardley is a must see. This was a very educational look at the value of maps, and the importance of knowing the landscape, looking at Evolutionary Flow and not just Process Flow when looking at optimisations. I would recommend the talk from Susanne Kaiser "Preparing for a future Microservices journey" from the day before as a nice companion to this keynote talk, as she used "Wardley Maps" to specifically look at the evolution towards microservices. (Though this keynote also shows that journey towards the end as well).

"Exploring your Microservices Architecture Through Graph Theory" from Nicki Watt was a great look at applying Graph Theory to distributed systems, especially with Microservices to gain insight into where architectural smells may exist using different analysis metrics.

The before lunch slot was "Awesome CI/CD Data Pipelines for Distributed Data-Sources" from Chris Burrell. This was a walkthrough of mining data sources (load and transform) from Microservices into RedShift in a pipeline approach.

"An Engineer's Guide to a Good Night's Sleep" had Nicky Wrightson giving a great Engineers Guide to Ops approach to building software, with 5 rules for building better systems so you don't have to be woken up at 3 am. Slides available here: https://speakerdeck.com/nickywrightson.

Matthias Noback presented "Beyond Design Principles and Patterns: Writing Good Object-Oriented Code" which was a great look at Object-Oriented code done right, in a nice succinctly laid out path from the ground up. I want to steal the whole thing as a blog post it was so well put together. Although there were code examples (Java?), the concepts given transcended across any OO language and presented in a nice language-agnostic way. Unfortunately, I didn't learn anything new, and I also had nothing to disagree with either.

Mufrid Krilic gave an interesting Lightning Talk: "Domain Model in Multi-Language Environment with Examples from Healthcare" which was a brief conversation about ubiquitous language when your code is in English but your domain is in Norwegian. This was from experience with a hospital software system.

To round out the weeks Lightning Talks was "Don't Rebuild your Monolith!" by Peter Anning. An epic tale of transformation from Monolith, to Microservices, regrets and reaffirmations. An entertaining watch with the takeaway that processes like DevOps, Agile and Ubiquitous Langage that come out of moving to microservices must be maintained and assimilated, lest we forget and the monolith grows back.

And last but not least, we have the final Keynote: "Temporal Modelling" from Mathias Verraes. A really good overview conversation into Event-based systems, Event Storming and why modelling the Events of your system is of greater benefit than to use Entity Modelling instead. Another recommended one to expand your thinking.

Summary

And that's a wrap! 2019 µCon is done and dusted. Lots to take in, lots to revisit from the recordings, and a bunch of sessions missed that need to be watched.

The amazing crew doing the filming have been working away getting all the videos up as quickly as possible (on the day recorded for the most part!). You can head over to Skills Matter and watch them all from the links provided off of the Schedule here. Take this and the previous part as a guide for where to begin but continue through all the other amazing talks I didn't have time to attend in person as well.

Happy Learning!

µCon 2019 - Day 1 & 2

Mark Clearwater — Fri, 31 May 2019 08:05:21 +0000

After a restful night at a London hotel (I learned my lesson from the last time I came in for a London conference) coffee and breakfast at the Business Design Centre in London, muCon 2019 kicks off. muCon (or µCon) is a Conference on Microservices, DDD & Software Architecture. From what I gather, this year for the first time it is an amalgamation of a DDD and Microservices conference into one. I'm here for three days. At this point, I've gotten into a rhythm of blogging about my Conference Experiences so here we go again!

Day 1

We kick off with an excellent keynote from Michael Feathers which captures various ideologies and principles applied to team and code architecture both at the class level, microservice level and interpersonal individual and team level as well.

NEW #muCon London 2019 #keynote #SkillsCast: @mfeathers explores system structures present in design to create simpler systems.

Click here for video: https://t.co/y2Y7F63BrB #SystemStructure #LegacyCode #MicroserviceArchitecture #Architecture pic.twitter.com/ApXVjdgbNA

— Skills Matter (@skillsmatter) May 29, 2019

As usual, the day is split into tracks, so I can only give experience on where I've been and guidance of which speakers and talks I would look out for in the future.

Following on from the keynote for me was "Microservices from Day One" from Richard Rodger. First-hand experience of building Microservices on a greenfields startup after literally writing a book on Microservices development, a chance to practice what he preached. An interesting takeaway that I liked was to design a message-centric system of components(microservices) and then the transport/routing layer doesn't matter (from a technology point of view). This resonates with me because it aligns nicely with the Ports and Adapters architecture.

NEW #muCon London 2019 #SkillsCast: @rjrodger shares how the startup https://t.co/GHuVLEqlZA succeeded in using microservices during their first 18 months of development and why it worked.

Click here for video: https://t.co/JJtjx7ccLj #microservice #architecture pic.twitter.com/jnCmbL15zL

— Skills Matter (@skillsmatter) May 29, 2019

Next up, and filling the pre-lunch slot was "Creating an Effective Developer Experience for Cloud-Native Apps" from Daniel Bryant. A great introduction and overview of DevEx, the idea of building a great experience for developers from coding to prod and beyond in the modern world of cloud-native, Kubernetes and Serverless. Whether it is "build or buy", cloud or in-house hosting, the story for developers to build, debug, test, deploy and monitor should be a first-class consideration of developing software.

NEW #muCon London 2019 #SkillsCast: @danielbryantuk explores the core concepts of the cloud-native developer experience and the lessons learned.

Click here for video: https://t.co/xaBmX4xpgL #continuousdeliveryprocesses #dx #devex #developerexperience pic.twitter.com/Ls2iTsagua

— Skills Matter (@skillsmatter) May 29, 2019

"The Gordian Knot" from Alberto Brandolini the importance of culture and the influence architecture plays on affecting that culture. Very interesting and a nice perspective on Conway's Law in many ways, and thinking about affecting change.

NEW #muCon London 2019 #SkillsCast: @ziobrando shares how to face a Gordian Knot problem by effectively using a DevOps approach.

Click here for video: https://t.co/4ZSESd9uCx #devops #softwarearchitecture #processes #microservices #architecture pic.twitter.com/VV92qAgS9G

— Skills Matter (@skillsmatter) May 30, 2019

"Strategic Domain-Driven Design Patterns" from Nick Tune was an interesting discussion on DDD grouping. Definitely a topic I need to read the (blue) book on, literally and figuratively. (Although I am told one does not simply "read" Eric Evans' Domain Drive Design...) Some very high-level patterns and approaches to help with finding groupings in your system.

NEW #muCon London 2019 #SkillsCast: @ntcoding shares how understanding domain patterns helps you align your microservices and business domain.

Click here for video: https://t.co/9d6ClArZJA #domainpatterns #ddd #microservices# architecture pic.twitter.com/8MOMVOS8FG

— Skills Matter (@skillsmatter) May 30, 2019

"Event Driven Collaboration" from Ian Cooper another look at the Reference Data concept, with some practical examples of what and how you might go about implementing this. A revision on the concepts of inside mutable data Vs outside immutable data, events, messages and caching.

NEW #muCon London 2019 #SkillsCast: @ICooper shares how events help us integrate our service architectures.

Click here for video: https://t.co/H7WMrEJtwF #eventdrivencollaboration #microservices #architecture pic.twitter.com/j4MBsnHeo5

— Skills Matter (@skillsmatter) May 30, 2019

The day wound down with a couple of Lightning Talks. A standout for me was "Continuous Visibility, No More Dashboards!" From James Brown on Continuous Visibility (CV). Using Alerts and notifications more, and only selectively add trends and maybe CI statuses to a physical dashboard where space is a premium (but don't forget to add GIfs!).

NEW #muCon London 2019 #SkillsCast: James Brown shares his journey on how he and his team evolved visibility on the health of their systems.

Click here for video: https://t.co/H7WMrEJtwF #operationalsupport #failurerecovery #syntheticmonitoring pic.twitter.com/DLu8EtKUkV

— Skills Matter (@skillsmatter) May 30, 2019

Day 2

Day 2 kicks off with another leading Keynote: "Getting to DDD: Pragmatic or Principled?" from

Julie Lerman. Julie gave a discussion on the DDD journey, engaging with new adopters, and how building on the concepts with a group slowly can be a great way to bring more people on board, without getting hung up on being too principled or having to be all in with everything DDD at once.

"Preparing for a future Microservices journey"

from Susanne Kaiser presented a journey from custom build through Microservices to Serverless taking all aspects of a hosted piece of software and it's infrastructure concerns transitioning through Build vs Buy, to commoditization.

“Software delivery performance is critical for tech organizations doing business today.” Microservices lessons learned with @suksr is happening now! 😎 #microservices pic.twitter.com/Ti4xehAkZC

— Skills Matter (@skillsmatter) May 30, 2019

"Observable Microservices" from Maria Gomez went through the what of observability (logs, alerts and tracing) along with the 'why' for the value it provides to you once your services are in production.

After lunch, David Leitner presented "Micro Frontends – A Strive for Fully Verticalized Systems". A nice definition of MicroFrontends and example architectures to add to your toolbox of "it depends" solutions. Very clearly outlined the when and where the different approaches are applicable. Definitely check out his work if your thinking about verticalized splitting your frontend.

This led into the afternoon Workshop: "Show me the Kubernetes" with Lewis Denham-Parry and Salman Iqbal. They walked us through the demos at github.com/CloudNativeWales/ShowMeTheKubernetes which worked well on a temporarily spun up cluster on Azure, or with a Minikube locally (instructions included in both cases). Further examples were promised so there might be more than the three we went through in the session.

To round out the second day was a keynote from Diana Montalion on Making a Case for Conceptual Integrity. I'm not too proud to admit that I didn't understand the term "conceptual integrity" at the end and couldn't give you the definition. However, the topic was very interesting and the steps discussed to reach the definition given were very useful and interesting in themselves that to me it didn't matter. Maybe I'm lacking the experience at this stage to accurately grok this, and others with more systems consulting experience and exposure did.

Just one of #muCon’s workshops happening this afternoon ⚙️Show Me the Kubernetes by @soulmaniqbal and @denhamparry offers hands-on experience for anyone new to #kubernetes! #SoftwareArchitectures pic.twitter.com/4yiwC0CbEy

— IkeAtSM (@IkeAtSM) May 30, 2019

Summary

Of course, most if not all of the talks were recorded and appear online (links added where available) but as usual you have missed the hallway conversations by not being here. These are usually the best part of any conference and this has been no exception. One great conversation leads to quoting the statement that never had anyone said or seen a system that would be described as too gold plated, or too well tested. Most systems instead suffer from not being of a good enough quality or lacking in test coverage.

In other conversations being able to share structures and strategies gives insight into what is or isn't working for other teams and companies and gives a relative look at where they are on their journey compared to you with yours. But based on the guidance and experience of others here, we all seem to be heading in a similar direction through SOA to DDD and Microservices.

Stay tuned for a summary of my day 3 experience.

Looking Back on C# 7: throw expressions

Mark Clearwater — Mon, 27 May 2019 22:30:00 +0000

Throwing Exceptions is both a blessing and a curse in C#. You can throw from anywhere to unwind the stack. But adding exception throwing and handling code can cause overheads that you need to be wary of. Not to mention making the code harder to reason about with control flow.

Regardless, we have them, and we use them, so the language should make that as easy as possible to do so. with C# 7 this was enhanced to support using throw as an expression. Up until this point, it was always a statement, which means there are places in the code that throw could not go.

One new language feature that only supports expressions and not statements is the Elvis Operator (or Null Conditional Operator, which we already looked back at) and another is the null coalescing operator. When it comes to validating code, these two features shine together.

public MyClass(string firstArg, string secondArg, Widget widget)
{
    if(firstArg is null)
    {
        throw new ArgumentNullException(nameof(firstArg));
    }
    if(secondArg is null)
    {
        throw new ArgumentNullException(nameof(secondArg));
    }
    if(widget is null)
    {
        throw new ArgumentNullException(nameof(widget));
    }

    _firstArg = firstArg;
    _secondArgLength = secondArg.Length;
    _widget = widget;
}

So verbose! wouldn't it be nice to collapse it together a bit? With throw expressions, we can.

public MyClass(string firstArg, string secondArg, Widget widget)
{
    _firstArg = firstArg ?? throw new ArgumentNullException(nameof(firstArg));
    _secondArg = secondArg?.Length ?? throw new ArgumentNullException(nameof(secondArg));
    _widget = widget ?? throw new ArgumentNullException(nameof(widget));
}

So much shorter and more concise. This saves typing time and reading the time. The magic is that the right-hand-side of the null coalescing operator has to take an expression that evaluates to the right type. Because throw is now an expression, it can do exactly that and satisfy the compilation.

Also remember how we looked at Expression body members in C# 6 and more in c# 7? Well as the name suggests, the body is an expression. Now that we have throw expressions, the bodies can use them too!

public class Widget
{
    public Widget() => throw new ArgumentException("Requires arguments, none provided.");

    public ~Widget() => throw new NotSupportedException("What are you building that needs a destructor, anyway? (Just curious.)");

    public string MyValueProperty => throw new NotImplementedException();

    public decimal CalculateTheAnswer() => throw new NotImplementedException();

    private T[] _items = new T[100];
    public T this[int i]
    {
        get => _items?[i] ?? throw new Exception("Not initialised somehow.");
        set => throw new NotSupportedException("An interface made me do this.");
    }
}

There are other use-cases out there, expressions are used all over the place. But I will leave that as an exercise to the reader to discover along the way.

Looking back on C# 6: Initializers

Mark Clearwater — Mon, 29 Apr 2019 23:30:00 +0000

Initializers have had a few upgrades since the early C# days. But before we look at more recent changes, we will review what came before.

Initializers or Object Initializers is a name given to code that performs the initial setup of a piece of memory (a struct or an object). Constructors are part of this but the idea goes more towards the holistic setup of the object data for all of the state you care to set up.

Taking a look at C for even more background, we have initializers like so:

struct MyType { char s; int n; };

// We can initialize a variable using a curly brace syntax:
MyType x = { 'a', 42 };

What we see above is that we are initializing our variable x to have its data for .s and .n set to 'a' and 42 respectively. This is initialization. Now using C#, something more familiar:

public class Foo
{
    public string Name { get; set; }
    public int Number { get; set; }
}

// Without using initializers:
Foo myFoo = new Foo();
myFoo.Name = "a";
myFoo.Number = 42;

// In C# we can initialize in a similar way to C.
// This code compiles to the same instructions as above:
Foo myFoo = new Foo() { Name = "a", Number = 24 };

// Collections also support initialization
int[] myArray = new int[] { 1, 1, 2, 3, 5, 8 };

I won't go into how C has advanced its own initializers, that it a different topic. Instead, we will look at how C# has taken this simple initializer above and enhanced in C# 6 on top of this initial syntax in C# 3.

Add Extension support for collections

When Initializers were implemented (or not long after if my memory deceives me) there was a little magic that made this work. Namely, the code written was simpler and more concise, but the implementation transformed into something more familiar.

The same is true for Collection initialization. If we review the example from above we can see this:

// Collection initialization
int[] myArray = new int[] { 1, 1, 2, 3, 5, 8 };

// The same code, more verbosely:
int[] myArray = new int[];
myArray.Add(1);
myArray.Add(1);
myArray.Add(2);
myArray.Add(3);
myArray.Add(5);
myArray.Add(8);

Basically, the syntax is a shorthand for calling Add( on the collection. This allows for more complex situations where Add can take multiple arguments.

var myDict = new Dictionary<int, string>() { { 1, "One" }, { 2, "Two" } };

// This worked the same way as the last example. The same code is:
var myDict = new Dictionary<int, string>();
myDict.Add(1, "One");
myDict.Add(2, "Two");

Again, this is all existing syntax. With C# 6, an ability was added so that instead of needing to implement Add on your type, you could create extension methods as well:

public static void Add(this Dictionary<int, string> dict, Foo value)
{
    dict.Add(value.Number, value.Name);
}

Foo foo1 = new Foo() { Name = "One", Number = 1 };
Foo foo2 = new Foo() { Name = "Two", Number = 2 };
var myDict = new Dictionary<int, string>() { foo1, foo2 };

At this point, the possibilities are endless and fully customizable to create your own Domain-Specific-Language (DSL). You don't even have to use Collections because anything can have an Add overload added via an extension.

Index Initializer

Dictionary syntax is a bit odd. Add isn't really the right approach. And we already have indexer syntax:

var myDict = new Dictionary<int, string>();
myDict[7] = "seven";
myDict[9] = "nine";
myDict[13] = "thirteen;

Why not extend Initializers to use the indexer as well? They did. C# 6 again.

var numbers = new Dictionary<int, string> {
    [7] = "seven",
    [9] = "nine",
    [13] = "thirteen"
};

Works as expected, and is the same result as the code above. This works off of the same existing indexer pattern( in a similar manner to the Add usage earlier), so works with any custom indexer on any custom type.

// Using an existing type from Newtonsoft.Json:
var x = new JObject { ["x"] = 3 };

Auto property initializers

That is a bunch of consumer side initialization. There was more added behind the scenes in C# 6 as well.

The humble Auto Property:

public int X { get; set; }

First, we can now give a default initialization:

// This is the same as `X = 4` in the constructor
public int X { get; set; } = 4;

And to make this trick even more complete, we have the getter-only property:

public int Y { get; } = 42;

As well as the ability to initialize this from a constructor instead:

public class MyFoo
{
    public int Y { get; };    

    pubilc MyFoo()
    {
        Y = 42;
    }
}

Sometimes you may have many constructor overloads, using the property initializer is less code duplication. Sometimes you may want to have different values for different overloads, then you can initialize in the constructor.

Either way, this gives you true power over you read-only without the verbose equivalent you used to have to write:

// Same code as above in "full":
public class MyFoo
{
    private readonly int _y;
    public int Y
    {
        get
        {
            return _y;
        }
    };    

    pubilc MyFoo()
    {
        _y = 42;
    }
}

The newer way is much more concise, especially when there are many properties:

// Just imagine how many lines of code this would be the old way!
public class MyFoo
{
    public string X { get; } = "Foo";    
    public int Y { get; } = 42;    
    public decimal Z { get; } = 54m;
    public object Key { get; } = new object{};

    // Other read/write props
    public int Another { get; set; }
    public bool Widgets { get; set; }
}

Wrapup

Object initialization had a major revamp in C# 6. How many of these do you use regularly? How many do you notice in your own code bases? These have been around for a while so expect only to see more of it. Do yourself a favour and start using it if you haven't already. Very readability, much fewer keystrokes. Canonical? You betcha!

Looking back on C# 6: String interpolation

Mark Clearwater — Sun, 14 Apr 2019 23:30:00 +0000

String Interpolation is a great feature that I now use everywhere I can (Except logging - see below).

We have efficient libraries to format strings for us, so we don't have to concatenate all the time. This is both convenient and performant.

var string1 = "My name is " + "Mark";
var string2 = String.Format("My name is {0}", "Mark");

The resulting string above is equivalent but there are many benefits to the second option:

faster internal string building for larger strings with multiple parameters
Lazy execution means you can pass template + args down the stack and format later (or never as an optimisation when necessary such as Debug/Verbose logs)
Potentially more readable as a template than the concatenation would be (depending on the message).

The problem becomes we have all these index positions. It is very easy with many arguments to either get the positions wrong or to change it and make a mistake.

String Interpolation

You can think of String Interpolation as the compiler automatically turning your string into a String.Format for you. (Oversimplification but useful way to conceptualise it.) The first piece of magic is the $ character. Adding this to the start of a string makes it into an interpolated string. This now grants special power to the braces ({}). When you have a block of braces inside the string, this essentially becomes an expression. You can put whatever code you want in here, and it becomes a format argument. This gives improved readability.

var oldWay = String.Format($"{0} is {1} years old.", p.Name, p.Age);
var newWay = $"{p.Name} is {p.Age} years old.";

Mistakes are easier to spot
compile-time checks performed on the string and its format
performant - same benefits of String.Format applied for optimisations
readable - reads like a sentence with clearing understanding of where the arguments come from

You can still use { in your string, you just have to escape it with another {:

var name = "bob";

// This becomes: {"name":"bob"}
var json = "{{""name"":""{name}""}}";

This is a canonical language feature, and you will expect to see most string-related code using it. That is if you are not already yourself.

Why "Except Logging"?

Turns out, there is a massively useful feature with logging using Microsoft.Extensions.Logging and ILogger. Semantic Logging, also known as Structured Logging.

Semantic/Structured Logging supported is up to the implementor of the logging, but Serilog, Application Insights, NLog and others tend to support this feature, and it is defined as a first-class part of the API.

The main difference to String.Format is you give named parameters in the template rather than numbered.

String.Format("My name is {0}", "Mark");
_logger.LogInformation("My name is {FirstName}", "Mark");

Anyone who has actually monitored their logs knows that templates are really valuable. You can find all instances of a log message quickly with templated arguments, rather than having to do a wildcard search with inlined values because each message is a unique snowflake. Most logging frameworks add the arguments as named metadata, using the value from the string (in the above example that would be FirstName).

This works great. As long as you don't use the new and useful String Interpolation when you log. String Interpolation results in a string passed to the logger, rather than passing a template and arguments, so it's one or the other at this time.

As you would expect, people really want this to reverse-engineer from String Interpolation into Semantic Logging automatically, but the argument is that it is both unexpected and a breaking change so you probably won't see that anytime soon without a custom library or API involved.