Perceived most of the time working on a software project, I’m thinking about good names for variables, classes, controls or other elements. I remember a statement from a smart developer, who says, that the real challenge of a professional software developer isn’t to find a good solution to a problem, rather than finding good naming conventions to describe the things in code. I totally agree to that!
Sometimes there is this one problem you are solving over and over again: Every time from scratch. After solving it in one way, this solution is removed from your brain (do you know Dr. Walter Bishop?) and on the next project you have to think about it again and maybe solve it in another way. This isn’t the most efficient way to work ;-)
Finding appropriate names for custom control categories is my personal recurring problem. I don’t know how often I have thought about good names to categorize the variety of custom controls in Silverlight or WPF. The major problem is to find category names that let you easily split up all your controls in groups, without thinking much about it. I came to the conclusion, that this is much easier if you have comprehensive examples for each category. This is exacly what I’ve tried in the next section. Let me know what you think.
The first category is for primitive controls like Rectangles or Ellipses, but also for controls, that are used to just display or visualize data (like a progress bar or text block). The main purpose is not to interact with these controls (even if there are potential events for that). That says, that all visualization controls (like gauge controls, KPI’s or graph controls) are belonging to this category.
Invisible Layout Container
The next section is for invisible layout containers. The main purpose of an invisible layout container is to lay out child controls in a specific layout (like a stack panel in vertical or horizontal way). Even if the controls have properties to set a background color, they are mostly used to just define the layout.
If a control is used to hold a child element and defines a visualization by itself, it belongs to this category.
Input controls are controls that are mostly used to change a value. If you think about it, even a GridSplitter is an input control, because it’s main purpose is to change the width of grid columns.
Button / Interactive Controls
Button controls are all kind of interactive controls, which are used to fire events or behave on mouse clicks.
If a layout container can hold more than one child element and maybe the user is able to select an item, it belongs to this category.
Extended Layout Container
The last category is an extension to the layout container category. In the real world you would not devide these two categories, therefor they are too similar. This category is for layout containers which can hold more than one child (e.g. master-detail-container) or it’s job is to animate it child elements (e.g. animated navigation container).
To validate these categories, I took my last major project and tried to put all controls (~50 different controls) in one of these categories. For 95% of the controls it works like a charm: Without thinking much about it, I quickly found an appropriate category for each control. For the last 5% of the controls / containers I had to think a little bit more about it and most often had to decide between two categories. That wasn’t much of a problem after recalling the boundaries of the categories, but let me know if you think these boundaries aren’t clear enough or too fuzzy.
Last thing I want to point out is that I’m going to merge the three layout container categories (Invisible Layout Container, Layout Container and Extended Layout Container) to one in future projects. In conclusion I came up with the following category names (or folder names in future solutions):