//<Name>Avoid the Singleton pattern</Name>
warnif count > 0
from t in Application.Types
where !t.IsStatic && !t.IsAbstract && (t.IsClass || t.IsStructure)

// All ctors of a singleton are private
where t.Constructors.Where(ctor => !ctor.IsPrivate).Count() == 0

// A singleton contains one static field of its parent type, to reference the unique instance
let staticFieldInstances = t.StaticFields.WithFieldType(t)
where staticFieldInstances.Count() == 1

let staticFieldInstance = staticFieldInstances.Single()
let methodsUsingField = staticFieldInstance.MethodsUsingMe
let methodsUsingField2 = methodsUsingField.Concat(methodsUsingField.SelectMany(m => m.MethodsCallingMe))

select new { 
   
t, 
   
staticFieldInstance,
   
methodsUsingField2,
   
Debt = (3*methodsUsingField2.Count()).ToMinutes().ToDebt(),
   
Severity = (10+methodsUsingField2.Count()).ToMinutes().ToAnnualInterest()

}

//<Description>
// The *singleton pattern* consists in enforcing that a class has just
// a single instance: http://en.wikipedia.org/wiki/Singleton_pattern
// At first glance, this pattern looks appealing, it is simple to implement,
// it adresses a common situation, and as a consequence it is widely used.
//
// However, we discourage you from using singleton classes because experience
// shows that **singleton often results in less testable and less maintainable code**.
// Singleton is *by-design*, not testable. Each unit test should use their own objects
// while singleton forces multiple unit-tests to use the same instance object.
//
// Also the singleton static *GetInstance()* method allows *magic* access to that 
// single object and its state from wherever developers want! This potentially
// attractive facility unfortunatly ends up into *unorganized*/*messy* code that 
// will require effort to be refactored. 
// 
// More details available in these discussions:
//  http://codebetter.com/patricksmacchia/2011/05/04/back-to-basics-usage-of-static-members/
//  http://adamschepis.com/blog/2011/05/02/im-adam-and-im-a-recovering-singleton-addict/
//</Description>

//<HowToFix>
// This rule matches *the classic syntax of singletons*, where one   
// static field hold the single instance of the parent class. We underline that  
// *the problem is this particular syntax*, that plays against testability.
// The problem is not the fact that a single instance of the class lives 
// at runtime.
//
// Hence to fix matches fo this rule, creates the single instance 
// at the startup of the program, and pass it to all classes and methods
// that need to access it.
//
// If multiple singletons are identified, they actually form together a 
// *program execution context*. Such context can be unified in a unique
// singleton context. Doing so will make it easier to propagate the 
// context across the various program units.
//
// The estimated Debt, which means the effort to fix such issue,
// is equal to 3 minutes per method relying on the singleton. 
// It is not rare that hundreds of methods rely on the singleton
// and that it takes hours to get rid of a singleton, refactoring
// the way just explained above.
//
// The severity of each singleton issue is **Critical** because as
// explained, using a the singleton pattern can really prevent the 
// whole program to be testable.
//</HowToFix>