Group related documents

Related documents are grouped into the same control. The idea behind this is that documents that are likely to be maintained together should be positioned very close to each other. This comes very convenient when a change in one of the involved documents is likely to require a change in the other documents as well. Furthermore, grouping documents saves a lot of space on the screen, allowing for many more documents to be shown.

Documents are considered related if their names match, substituting wildcards for some parts of the names.

Example: Suppose we have a class GraphModel in which the documents listed below are involved. Touching the graph model typically affects each of those documents. Adding a property or some logic to the graph model requires to add this stuff to the class' declaration and implementation at least. In addition, we often also want to make this property or logic accessible through the interface, and we want to have it covered by the unit test.

IGraphModel.h : an interface in front of the graph model
GraphModel.h : the graph model's declaration
GraphModel.cpp : the graph model's implementation
GraphModelTest.cpp : a unit test for the graph model

Substituting wildcards for prefix I, suffix Test and extensions h and cpp, those documents are represented as in the figure above. Also notice the visual indication (imposed by the style rule "Mark the last activated document within the group") that GraphModel.cpp is the most recent one to have been activated. The latter will be activated again when clicking the group rather than one of its documents.

Extensions

Wildcards are substituted for the given extensions when comparing document names. Hence, documents with the same name except for a different extension are grouped into the same control. By default, the option "All" is checked, which means that the grouping applies to all extensions, not only to the given ones.

Example: Documents HelpWindow.h, HelpWindow.cpp and HelpWindow.html appear as a group labeled HelpWindow, containing documents labeled h, cpp and html respectively, if these latter are given as extensions.

Typical usages:

For C++ developers it is obvious and quite essential to at least have a class' header (usually .h file) and corresponding implementation (.cpp file) grouped. Whenever adding / removing / changing a data member or a method declaration in the header, corresponding changes need to be made to the implementation as well.
For UI development in Windows Forms applications, C++, C# and Visual Basic .NET developers typically handle the code (.h, .cs or .vb) and designer (.h [Design], .cs [Design] or .vb [Design]) documents together. Changes made to the UI in the designer view usually require corresponding changes in the code.
Similarly, in WPF projects developers typically group their XAML documents (.xaml) and underlying code (.xaml.cs or .xaml.vb). E.g. EditorWindow.xaml and EditorWindow.xaml.cs.
In ASP.NET wep applications we recommend to group the designer / markup documents (.aspx) and the code behind them (.aspx.cs or .aspx.vb).
Web developers often have dedicated scripts and/or style sheets for some or each of the HTML files, and want to have them grouped even if they are in different folders. E.g. gallery.htm, gallery.css and gallery.js.

Suffixes

Wildcards are substituted for the given suffixes when comparing document names. Hence, documents with the same name except for a different suffix are grouped into the same control.

Example: Documents GraphModel.cs, GraphView.cs and GraphPresenter.cs appear as a group labeled Graph*.cs, containing documents labeled Model, View and Presenter respectively, if these latter are given as suffixes.

Typical usages:

Popular architectural patterns include Model-View-Controller, Model-View-Presenter, Model-View-ViewModel and Model-View-Adapter. The end of a class' name often indicates its role in the pattern. Usually these classes are to be handled together, e.g. in a Model-View-ViewModel pattern for a dialog, adding a property which has to be configurable in the dialog requires adding code to each of the Model, ViewModel and View classes.
In C++, if a templated class or method has an implementation in a different file, such a file is usually called MyClassExt.h, MyClassImpl.h or MyClassFwd.h. Typically one wants to have it grouped with the declaration file.
Class name suffixes definition (or def) and runtime are often used to distinguish between those respective roles of an algorithm that can be configured by the user. E.g. TagCloudGeneratorDefinition.cs and TagCloudGeneratorRuntime.cs. Some users like to have them grouped.
Observer classes are often named after their subject, e.g. Configuration.vb and ConfigurationObserver.vb.
Classes that are meant to test another class programmatically (unit testing) are often named correspondingly, e.g. SearchTree.cs and SearchTreeTest.cs.
Some classes that are accessible from a higher level in the application (e.g. higher packages or namespaces) have a counterpart class that is only accessible within the same package or namespace. Such classes may have suffixes public and private respectively in their names and can hence be grouped.

Substrings

Wildcards are substituted for the given substrings when comparing document names. Hence, documents with the same name except for those substrings are grouped into the same control.

Example: Documents ContactFormEmailValidator.php and ContactFormPhoneValidator.php appear as a group labeled ContactForm*Validator.php, containing documents labeled Email and Phone respectively, if these latter are given as substrings.

Prefixes

Wildcards are substituted for the given prefixes when comparing document names. Hence, documents with the same name except for a different prefix are grouped into the same control.

Example: Documents SimpleHelperFunctions.cs and AdvancedHelperFunctions.cs appear as a group labeled HelperFunctions.cs, containing documents labeled Simple and Advanced respectively, if these latter are given as prefixes.

Typical usages:

Class interfaces are usually prefixed with an i. Especially when an interface has just a single implementation (e.g. ChartModel.vb and IChartModel.vb) it is appropriate to group those together.
The various flavors of the same concept or the various implementations of the same interface are often indicated with a different prefix. E.g. IDataInterpreter.cs, XmlDataInterpreter.cs and TxtDataInterpreter.cs. Because of their similarities these documents typically need to be maintained together.
Prefixes are often used to indicate namespaces. The same concept (e.g. a customer order) may appear in multiple namespaces, in multiple layers of the application, e.g. model_customerorder.cs, app_customerorder.cs and ui_customerorder.cs, all of which are usually handled together.
Abstract base classes and their concrete subclasses can often be identified by their prefix. E.g. AbstractSearchTree.vb, RedBlackSearchTree.vb and AVLSearchTree.vb.