I’ve just encountered one of those wonderful bugs caused by Windows path length limits. In this case a large part of the problem was a file with a name over 100 characters long. Most of this name duplicated information already known due to its context, such as the namespace it belonged to. When moving between environments a longer base path in the new environment resulted in an over-long file path and hence breakage in what was previously a working codebase. The base path in the new environment was not excessively long, the fault here is purely with a poorly chosen filename.

Another area I see this is naming projects within Visual Studio solutions. I’ve always favoured short(ish) names comprised or two or three words describing the purpose of the project. This conveys some relevant meaning and can be kept reasonably concise. I’ve also worked on systems where the project name matches the base namespace of the generated assembly. I find a number of problems with this approach:

• This immediately introduces duplicate information. Generally the first elements of a namespace are the client and/or project. This is almost always identifiable by the solution in which the project resides. Adding it to every project adds no value.
• The more relevant component to a developer is the specific project but this information is given less precedence than the common (irrelevant) portions. Depending on tool window size it may be obscured.
• Not all projects contain a single root namespace. (Such projects should be minimised but are not always avoidable).
• Adding the redundant information wastes character from a sometimes limiting 260 character maximum. This increases the risk that moving to a different environment (say a development machine to a build server) will fail due to path lengths.

I’ve mostly encountered this problem with build servers, but it can be a problem even if you never chose to automate your build process (note: you should automate your build process). In the past I’ve had issues caused by an installer generator that ran out of path length when building its own temporary directory structure while I was attempting to build an installer for a relatively standard system that had some excessive file lengths.

In an ideal world we could assign names as long as we’d like and everything would just work. Windows is not this ideal world and we need to deal with its reality. Additionally the kind of redundancy I’ve just discussed does nothing to convey useful information and may therefore be considered overhead. Pruning it to size is therefore a win in multiple ways.