The feature we’re most excited about with TDS 4.0 is support for naming conventions. Most of us work on teams that contribute to the same code base. It is important that the unified product of that team’s effort be presented consistently no matter who contributed the code. Choosing to name variables or functions a certain way can make your framework more cohesive and easier to use by everyone.
By default, Test Design Studio comes pre-configured for the most basic naming conventions around character casing for language elements. These defaults are based on generally accepted industry norms for VBScript and include:
- Variables and parameters start with lower-case letter and capitalize each new word.
- Functions, subs, and properties start with upper-case letter and capitalize each new word.
- Class names start with upper-case letter and capitalize each new word.
- Constants use all upper-case letters with underscore between words.
The following illustrates a Sub whose name begins with a lower-case letter instead of upper-case
The violations for naming rules are displayed in the Error List along with any syntax errors and code analysis feedback. Each violation is also underlined in the editor with green “squiggles” to draw attention to the oversight.
These default rules are a great start for naming conventions, but individual policies at your organization are likely far more complex. Since every organization is different, we designed this feature from the beginning to be user-driven. All naming conventions are based on a series of rules in an XML-formatted file. We’ve provided a powerful set of criteria to help you define your individual conventions. We’ve even provided a working sample of a much more complicated rules file that you can use as a template for your own rules (look at ‘CodeAnalysis\rules.sample.typePrefix.xml’ under the TDS installation directory).
Not only can you define different rules based on item type (e.g. Sub, Function, Variable), you can also define rules based on the content. Do you name integer variables one way and boolean variable another way? No problem! Different convention for public vs. private items? We have that, too!
You can change the location of the naming rules XML file in the same spot where you turn individual code analysis rules on/off by selecting “Tools –> Options” from the main menu.
While we’ve tried to prepare a solid foundation for the rules engine, we know our customers will be the truest test of when the feature is complete. We fully support the functionality, but are releasing it under a “Beta” tag for now. We’re confident in the core functionality for the default rules we have provided, but we need to hear from more customers about how they want to implement rules.
If you are unable to implement your naming conventions using our present rules engine, we want to hear from you! Please contact us with examples of the rules you want to implement. If we can’t make the current rules engine work, we’ll see what we can do to add the support your need.
We hope you enjoy this new feature, and look forward to hearing your feedback.