Team Foundation Server Working Practices

Over the years, I have continued to refine the working practices my teams use when using Microsoft Team Foundation Server (TFS) as the application life cycle management (ALM) tool for work item tracking and version control.  Here are my current recommended practices.

Check-Out Policies

Source code, XML and all ASCII-based files shall not be locked when checked out.  Multiple developers are permitted to work concurrently on files, subject to the directions in the Check-In Policies.

Check-In Policies

The Source code policy below has been kept deliberately simple to avoid unnecessary restrictions being placed on the developers.

Peer Reviews All production code should be peer-reviewed.  Peer reviewers should ensure that

• all of the quality markers covered in the Standards and Practices are followed

• unit testing is appropriate

• business logic is present in the appropriate layers

• logging has been applied in line with expectations

• NFRs have been appropriately considered

• No new compiler warnings have been introduced

Coding Standards

Visual Studio’s Code Analysis (CA) feature reports information, such as violations of the programming and design rules set forth in the Microsoft .NET Framework Design Guidelines.  The standards are mandatory unless where otherwise explicitly stated otherwise.

The following rules shall be set to “Warnings as Errors” – meaning that the solution will not compile if any of these errors occur. This list may be reviewed as appropriate.

• CA1001: TypesThatOwnDisposableFieldsShouldBeDisposable
• CA1002: DoNotExposeGenericLists
• CA1005: AvoidExcessiveParametersOnGenericTypes
• CA1006: DoNotNestGenericTypesInMemberSignatures
• CA1007: UseGenericsWhereAppropriate
• CA1010: CollectionsShouldImplementGenericInterface
• CA1011: ConsiderPassingBaseTypesAsParameters
• CA1021: AvoidOutParameters
• CA1024: UsePropertiesWhereAppropriate
• CA1026: DefaultParametersShouldNotBeUsed
• CA1030: UseEventsWhereAppropriate
• CA1031: DoNotCatchGeneralExceptionTypes
• CA1034: NestedTypesShouldNotBeVisible
• CA1044: PropertiesShouldNotBeWriteOnly
• CA1049: TypesThatOwnNativeResourcesShouldBeDisposable
• CA1050: DeclareTypesInNamespaces
• CA1051: DoNotDeclareVisibleInstanceFields
• CA1058: TypesShouldNotExtendCertainBaseTypes
• CA1061: DoNotHideBaseClassMethods
• CA1062: ValidateArgumentsOfPublicMethods
• CA1063: ImplementIDisposableCorrectly
• CA1064: ExceptionsShouldBePublic
• CA1065: DoNotRaiseExceptionsInUnexpectedLocations
• CA1500: VariableNamesShouldNotMatchFieldNames
• CA1502: AvoidExcessiveComplexity
• CA1504: ReviewMisleadingFieldNames
• CA1505: AvoidUnmaintainableCode
• CA1506: AvoidExcessiveClassCoupling
• CA1800: DoNotCastUnnecessarily
• CA1801: ReviewUnusedParameters
• CA1804: RemoveUnusedLocals
• CA1805: DoNotInitializeUnnecessarily
• CA1806: DoNotIgnoreMethodResults
• CA1807: AvoidUnnecessaryStringCreation
• CA1811: AvoidUncalledPrivateCode
• CA1818: DoNotConcatenateStringsInsideLoops
• CA1819: PropertiesShouldNotReturnArrays
• CA1823: AvoidUnusedPrivateFields
• CA2104: DoNotDeclareReadOnlyMutableReferenceTypes
• CA2124: WrapVulnerableFinallyClausesInOuterTry
• CA2200: RethrowToPreserveStackDetails
• CA2201: DoNotRaiseReservedExceptionTypes
• CA2205: UseManagedEquivalentsOfWin32Api
• CA2214: DoNotCallOverridableMethodsInConstructors
• CA2242: TestForNaNCorrectly

In cases where it may be appropriate to suppress a particular condition, this can be done explicitly in the code through the use of Source Suppression attributes.  This should be done judiciously and justification provided – and documented in the “Justification” property of the attribute. Unit Testing code will not have CA applied as it is not a deliverable.

StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project. Each deliverable project will be configured for StyleCop “warnings as errors”. Together with the  are numerous points of failure in the development of a software solution:  check-in rules, this means that the code cannot be checked in without conforming to the defined standards.

All check-ins must be accompanied by linked TFS work items to describe the reason for change.  All check-ins must contain at least a short but usefult overview description or headline of the reason for change and the change itself.

The following guidelines shall also be followed:

  • Anonymous types should be avoided where practical
  • Anonymous methods should be avoided where practical (this does not affect use of lambdas)
  • Prefer implicit interfaces
  • Interface atomically
  • Use the event aggregator for event subscription/publishing
  • All method names are verbs or contain verbs
  • Prefer properties to methods
  • Always use XML comments for properties, always specify if it Gets and/or Sets
  • XML comments must describe behaviour and never implementation
  • No magic numbers other than 0, 1, -1
  • String literals are held in resource files
  • Never throw Exception, only ever derived exceptions. Treat Exception as though it were abstract
  • Offensive programming: All TODOs must be accompanied by NotImplementedException and vice versa
  • Use LINQ queries in preference to LINQ extension methods
  • Use LINQ queries in preference to loops
  • Only evaluate LINQ expression trees at the last possible opportunity
  • Never apply extension methods to system.object
  • All view objects (controls, label, elements in the rendered HTML) must include a unique identifier accessible by the test automation framework.  This identifier must persist each time the view is rendered but be unique within the application
  • Zombie code is prohibited.  Under no circumstances may code that has been commented out be checked in to the source control repository; such lines must be removed prior to check-in
  • Yoda conditions are to be preferred over      traditional comparators.  Constants,      literals, nulls and read-only members must be presented to the left of equality operators E.g.

if (null == foo)                Favoured

if (foo == null)                Disfavoured

Whilst it is not mandatory to apply the coding standards to Unit Testing code or to Stubs/Fakes, it is encouraged.  StyleCop warnings shall be promoted to errors only on production code.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s