Using Statements Management
Using Statement Management Definition:
Guidelines for reducing the length of Type signatures in Classes, Interfaces and Methods and the management of unused declarations for better understanding the Software Entity’s Intent
Using Statement Management Justification:
A Using Statement is a declaration at the top of all C# Type files. This declaration is a reference to a Namespace and prevents “Code Noise” but eliminating the need for a fully qualified name for the Types being consumed within the code blocks inside the C# file.
The using statements also act as abstraction of the Dependencies that the Class requires to operate correctly. This is the justification for removing unused statements as they obscure the overall intent of the Software Entity, the Class.
Using Statement Management Standards:
You have a responsibility to manage the Using Statements to make your code more readable to other Developers.
Best Practice:
using Proxy.WCFService;
var ccRequest = new CustomerContactsDtoRequest();
Undesirable Practice:
var ccRequest = new Proxy.WCFService.CustomerContactsDtoRequest();
You have a responsibility to manage the Using Statements to prevent declarations of Namespaces that are not used.
using Portal.CustomerContacts.Data;
Tools like ReSharper will grey out unused statements allowing you to remove them safely
This is more than a cosmetic requirement. When a developer opens a Class and sees the declarations it should give that Developer a clear understanding of ALL Dependencies required for that Class.
If declarations are used defining dependencies not required it adds a level of misunderstanding that is not desirable. This adds to the learning curve and cost of Change Requests.
Remove all redundant fully qualified namespaces from Types to remove “Code Noise”
Undesirable Practice:
ServicesProxy.WCFService.CustomerContactsDtoRequest
Best Practice:
CustomerContactsDtoRequest
Using Statements can use “Aliases” to define a fully qualified Namespace declaration. A Namespace alias can solve ambiguity issues between common names within an assembly.
using PhoneFormatType = Portal.Common.Helper.MVC.CommonHelpers.PhoneFormatType;
The above PhoneFormatType is a common name between two Helper Classes, the Alias clearly defines the desired Type for Class use
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016