Our Development Ethos and Practices


This document outlines software development ethos we uphold when contributing to Warewolf. Each major bullet point is an ethos. And each sub-bullet point is the practices required to uphold each ethos. Any bullet points deeper than two levels add clarity / guidance for the action.

● I apply TDD.
○ When creating a new class I ensure it always has 90% Unit Test coverage via its Test Class
○ When amending an existing class I ensure it always has 90% Unit Test coverage via its Test Class.
○ I ensure any class with a reference to an amended class also has 90% Unit Test coverage via its Test Class.
○ I do not create a class and apply Unit Testing later. I develop Unit Test alongside my code.

● I prefer abstraction over concretes
○ I wrap .NET or third party objects in interface when none exist.
○ I create interfaces for the classes I create so as to avoid concrete references
○ I create reusable code


● I use construction injection over IOC containers.
○ If I encounter IOC container use, I remove its use and replace it with constructor injection
○ When creating new work that requires an IOC container, I will use constructor injection instead


● I follow the Boy Scout Principle
○ I refactor a class if I am amending it and it does not follow our Ethos and Practices
○ I ensure all Resharper violations listed in every class I touch are addressed as I work.
○ I ensure once a class is no longer used, I delete it.
○ I ensure Unit test coverage is at least 90% when modifying existing classes and classes with a reference to the modified class

● I Dispose / Cleanup resources I use
○ When using a disposable object I wrap it in a Using statement
○ Or ensure it is disposed manually if its scope crosses method calls
○ All streams opened by me, are be closed by me
○ When creating / using a class with class level variables that are disposable, I implement IDisposable and dispose these class level variables.


● I employ Defensive Programming Practices
○ I null check parameters coming into a method.
○ I log and handle exceptions gracefully.
○ I do not re-use inputs in a method. Instead I will assign to a new variable and use this.
○ I do not use multiple property drill down.
○ I do not use a property accessor more than once in a method.
○ I never manipulate a Property’s backing field, except to assign a value.
○ When prototyping to understand a concept or library I never take this code into production. It is deleted once I understand how it works.


● I use intent revealing naming for methods and variables.
○ I use logical method names that reveal what it is doing.
○ I use logical variable names that reveal what its purpose is.
○ I use logical test method names that reveal what is tested and what is expected.


● I follow other best practives as listed here :
○ I internally version Workflow Activities according to our Versioning strategy
○ When properties are added or removed I will create a new version of the activity

Ist dieser Artikel hilfreich?