Edit this page

1.1. What is this?

This document attempts to codify some of our coding principles. We want to write simple code that’s testable and easy to reason about. This isn’t a list of cast-iron tenets that must be applied at all times, it’s a collection of our experiences about how to make it simple.

This is intended to be owned by developers at Redgate. If you want to make a change to this style guide, please create an issue and open a discussion. The Tech Leads / Head of Engineering will listen to the discussion and make changes if needed.

1.2. Platform

Code should compile with the latest .NET Core. If that’s not possible (e.g. legacy packages or WinForms/WPF), then it’s the latest .NET Framework.

.NET Core is the future and we’re striving to get all code .NET Core compatible.

1.3. Basic principles

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. (Tony Hoare)

We choose the first way. Given a choice between A And B, pick the simpler solution. The rest of this provides our hard-earned experience of what simpler means.

1.4. On Testing

We require code to be covered by tests whenever possible and sensible. We aim for 100% coverage but we don’t necessarily expect to get there. We prefer fast tests whenever possible, and test suites which run under a second.

1.5 Using the Guidelines

New starters should read thirough the guidelines and reviews should reference this document. We try to use automated tools such as R# to minimize the number of times we need to return to this document.

1.6. Is this a coding standard?

We encourage projects to decide themselves which guidelines are important, what deviations a project will use and what kind of layout must be used for source code. Obviously, you should make these decisions before starting the real coding work and this should be documented in your repository and agreed with the Tech Leads / Head of Engineering.

To help you in this decision, We’ve assigned a level of importance to each guideline:

Guidelines that you should never skip and should be applicable to all situations

Strongly recommended guidelines

May not be applicable in all situations

1.7. When to apply the Coding Standards?

You should apply these guidelines to the code you write. We do this to make our code simpler to maintain in the future

If you have an exception to this, that’s cool. If it makes the code simpler and easier to reason about, then it’s a good exception.

1.8. Feedback

Use GitHub issues in this repository to provide feedback.

1.9. Credits

Dennis Doomen is the original author and we forked from