Using Directive Placement #312
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This repo has been placing
using
directives withinnamespace
blocks. The apparent benefit was occasional brevity for "nearby" namespaces: within theFixie.Tests
namespace, you could simply sayusing Assertions
to bring in the nearby namespaceFixie.Tests.Assertions
. This was the only benefit, and switching to it was a Pyrrhic victory for two reasons:namespace
directive below existingusing
directives. Fortunately most such conflicts would coincidentally surface as a compiler error based on usages of the identifier, but still: here be dragons.This reorders
using
vsnamespace
as a step towards cleanly applying implicit/globalusing
directives in a subsequent PR. By applying this code change separately from the implicit/globalusing
directives, each can be more easily reviewed in isolation.This was done manually. For each visited file, already-abbreviated
using
directives were first expanded to their fully-qualified equivalent, letting the IDE first confirm what the implied full name was. Once allusing
directives in a code file were fully-qualified, they could be safely cut and pasted before thenamespace
with confidence that the move could not alter the meaning of the following code.Two name conflicts were encountered and resolved:
Console
tends to be ambiguous in the tests when we can alternately meanSystem.Console
orFixie.Console
. We resolve this by always referring toSystem.Console...
explicitly in the tests, and can meanFixie.Console
implicitly otherwise.TestResult
can mean eitherMicrosoft.VisualStudio.TestPlatform.ObjectModel.TestResult
orFixie.TestResult
. We resolve this in bothVsExecutionRecorder
andVsExecutionRecorderTests
by including the following alias after the namespace declaration: