Consistency is a two edged sword

Maybe a series?

Consistency isn’t a goal in itself

In common with many other developers, I’ve often been asked to make changes on the basis of consistency. Many times those requests make perfect sense, and I’ve made the requested changes happily. But, sometimes, those changes don’t make sense – and I’ve had some very interesting (and frustrating!) conversations where people seem to think that consistency is more important than every other concern.

For example, consistency is frequently cited as a motivation for changes (or as a reason to maintain the status quo) over on the C# Language repository on GitHub. (This repo is where much of the design work for the C# languages happens in the open). Here are a few examples: #5513 - Inline type declaration without curly brackets – allowing a class or interface declaration with no members to be terminated with a semicolon ; instead of { braces }, for consistency with record declarations https://github.com/dotnet/csharplang/discussions/5513 #2098 – Switch expressions currently disallow trailing comma – described as consistent with existing collection initializers, but objected to as inconsistent with type definitions, parameter lists and so on. https://github.com/dotnet/csharplang/discussions/2098 #1246 - Allow trailing comma in tuples & argument lists – some see the benefit and are arguing for consistency with collection initializers, others see problems and argue for consistency with other language features. https://github.com/dotnet/csharplang/issues/1246 But here’s the thing. Consistency has, in and of itself, precisely zero value. That’s right – in isolation, consistency has no value at all. None. Consistency has value only to the extent that it permits other value. This might be reducing the number of different concepts, and thus decreasing the amount of learning required. Or it might be to improve recognition and simplify memory Let’s look at some ways that consistency is helpful – and some ways that it can be harmful.

Consider the changes Apple made between System 6 and System 7. In System 6, configuration changes were made via the Control Panel. Adding new Desktop Accessories or Fonts required using the Font/DA Mover.

This applies across all domains, both for developers (programming languages, APIs, user interfaces) and for everyone else as well (

Consistency is a good thing when it helps developers get their job done because things work the way they expect without having to reference manuals, read other documentation, ask a friend, or do a web search. When this happens, consistency saves time and improves productivity.

Consistency is a bad thing when it adds seldom used edge cases that developers don’t expect because they’re seldom seen and surprising when encountered. When this happens, consistency creates pitfalls and costs considerable time.

Those languages that I remember studying were unusable precisely because their rigid consistency made writing - and reading - the code difficult. Instead of simplifying things, the enforced consistency placed a higher cognitive load on the developer.

Forcing foolish consistency on C# would be ignoring the lessons we can learn from those older languages.

Good language design - as we’ve seen over the history of C# - involves achieving careful balance between consistency that creates predictability & productivity, and consistency that creates pitfalls and problems.