Succinc<T> v2.0.0 release notes

A few days ago, version 2.0.0 of Succinc<T> was released via nuget. As Succinc<T> follows the conventions of semantic versioning, the switch from 1.x to 2.0 is a clue that the release includes breaking changes. In addition though, a number of new features have been added. This release notes describes both the breaking changes and new features. Continue reading “Succinc<T> v2.0.0 release notes”

Arnolyzer: adding clean-code static analysis to C# in VS2015

arnolyzer-logoArnolyzer is a Roslyn-based analyzer for Visual Studio 2015 that provides a set of compiler rules that encourage modern, functional-orientated, coding standards in C# 6. Pure functions; no inheritance; no global state; immutable data classes and variables; and short, concise sections of code.
Continue reading “Arnolyzer: adding clean-code static analysis to C# in VS2015”

Generic variance in C#, part 3 – Covariance

csharp_genericsIn part 2 of this series, we looked at contravariance, which is a special case of generic variance, for interfaces that only allow instances of T, for ISomeInterface<T>, to be passed in, either via method parameters or through property setters (though good code will not contain the latter, of course). It’s perhaps no surprise that covariance is the opposite. Only when ISomeInterface<T> allows instances of T to be passed out (either via method returns, or property getters), can that interface be covariant.
Continue reading “Generic variance in C#, part 3 — Covariance”

Generic variance in C#, part 2 – Contravariance

csharp_genericsContravariance is perhaps the hardest of the three types of generic variance to understand (at least I found it so). This article hopefully takes the reader through two examples of its use to explain what it is, before showing how it’s used for real in the .NET Framework.

This is part 2 of a three part series on generic variance in C#. Part 1, covers invariance. The final part, covers covariance.
Continue reading “Generic variance in C#, part 2 — Contravariance”

Generic variance in C#, part 1 – Invariance

csharp_genericsC#’s generic types are, by default, invariant. Special cases of covariant and contravariant can be defined though. So what does that previous gobbledygook even mean? Hopefully this three-part article will help explain these three terms, and why they even exist in the first place.

The second part of this series, looks at what is probably the least well understood of the three terms: contravariance. If you feel you understand the other two terms, feel free to jump straight to that part therefore. The third, and last, part, looks at covariance and finishes with a summary of the difference between the three. But first, we start at the beginning: invariance.
Continue reading “Generic variance in C#, part 1 — Invariance”

The Rotten Domain Model is dead; long live the Abstracted Domain Model

abstractMany years ago, back when OO was a new, exciting idea that appeared to offer a panacea solution to developing applications, Martin Fowler wrote an article entitled “Anemic Domain Model” (ADM), in which he argued that separating data from functionality, within the OO paradigm, is an anti pattern.

Twelve years later, things have moved on quite a bit. Many now recognise the benefits of such a split; yet some still, near-religiously, stick to the idea that the anaemic data model is somehow “not real OO”. Part of this stems from the (presumably deliberate) use of a negative term to describe that separation approach. It’s therefore time to fight back with new definition of the terms “RDM” and “ADM”, to help move us away from the antiquated view that separating data from functionality is an anti-pattern. It’s the RDM that has been shown to be the real bad design approach.
Continue reading “The Rotten Domain Model is dead; long live the Abstracted Domain Model”

The slow death of agile

skullRecently, I heard of a job interview in which the applicant claimed on their CV that they worked for a “strict agile” company. At the time, I thought of this as a good thing. However, reflecting upon it, it strikes me as yet another example of a worrying trend around agile practices, namely treating only specific ways of working as being agile. “Strict agile” is really an oxymoron: it’s another sign that we are witnessing the death of agile through “processification”, or the setting in stone as to what “agile” can be. Continue reading “The slow death of agile”

Inheritance: just stop using it already!

no_inheritanceThere are certain constructs in programming languages that demonstrably lead to bad code in the vast majority of use-cases. There is a term for these constructs: anti patterns. An anti-pattern is a way of solving a problem that often appears quick and simple, but that leads to more work and more problems in the long run. Think of nailing two pieces of wood together, rather than drilling a guide hole and using a screw. The former is quicker, but the repair when the wood splits can be both costly and time consuming. Programming languages can enable, and sometimes even encourage, such anti-patterns. Whilst goto might be the best known, there are three other contenders for the worst anti-pattern of all: not writing automated tests, null and object-orientated (OO) inheritance. It’s the last that is the topic of this post. Continue reading “Inheritance: just stop using it already!”

Should programmers really stop calling themselves Software Engineers?

This post is in reaction to an article on the American publication website, The Atlantic, entitled “Programmers: Stop Calling Yourselves Engineers”. That article itself paints a rather silly, rose-tinted, picture of engineers and tries to argue that programmers don’t make the grade. This post isn’t (just) an attack on that article; it is an exploration of the various terms used to describe programmers and whether any are fit-for-purpose as a unifying term to describe those who code? Continue reading “Should programmers really stop calling themselves Software Engineers?”

Using Succinc<T> to overcome IEnumerable code smells

SuccincT
The IEnumerable<T> interface has numerous extension methods associated with it, including a number that return a single element if a match occurs, or return the default value for the type if that fails: FirstOrDefault, LastOrDefault, SingleOrDefault and ElementAtOrDefault. These methods create two code smells due to the nature of .NET’s type system. As of version 1.5.0, Succinc<T> offers alternatives to these methods that overcome those smells.
Continue reading “Using Succinc<T> to overcome IEnumerable code smells”