Enterprise Standards Management

One of the most important features of Total Visual CodeTools is its ability to manage development standards for single developers, project teams, and an entire enterprise. As projects become more complex, and entail greater staffing requirements, the need for standards in development becomes crucial.

Total Visual CodeTools tackles this problem by offering a powerful and flexible architecture for managing your standards.

• As a single developer, you can use Total Visual CodeTools to ensure that all your projects conform to the development standards dictated by the project. With support for multiple standards templates, you can customize standards according to a specific client's needs, or a particular project's requirements.
• As a team or enterprise developer, Total Visual CodeTools standards allow you to develop projects without worrying about whether or not you are conforming to the defined project standard.
• As a development manager, you now have a tool to define development standards, and enforce them among entire project teams.

Total Visual CodeTools uses Standards to define how your projects are created and updated. Standards define things like naming conventions, commenting style, and error handling. In order to use Standards effectively, it is important to understand the Standards architecture employed in the product.

Types of Settings

Total Visual CodeTools uses two types of settings to control how the product works and how standards are enforced.

• Shared Standards are the settings that are used throughout the Total Visual CodeTools tool set. These control development standards that can be shared by an entire team. Shared standards are stored in a central shared location so each developer using Total Visual CodeTools can seamlessly connect to the Standards repository and use the elements defined there. For example, naming conventions, commenting style, and error handling settings are Shared Standards. All Shared Standards are set and managed from the Total Visual CodeTools Standards form. This enterprise feature is extremely helpful in maintaining consistent coding styles across your development team, and is particularly effective for new members of your team or junior programmers.
• Local Settings are the settings that are assigned to a specific tool or developer and are unique to each installation of Total Visual CodeTools. These options are set by the developer from a specific tool's form. For example, the procedure type setting in the New Procedure Builder is an option that shouldn't be controlled centrally--it is up to the developer each time the tool is used. Another example would be the developer's initials used when generating comments. Local Settings are stored in the Windows Registry on the computer running Total Visual CodeTools and are therefore private to that developer.

How Settings are Created

Total Visual CodeTools stores all Shared Standards in one or more Shared Standards files. When you first install the product, a default file is created in the directory you specified for installation. This file contains reasonable defaults--if you are a single developer and want to get started right away, the default settings will most likely be appropriate.

You can modify any Shared Standards to match your development style and standards. Additionally, you can save multiple settings in multiple Shared Standards files. This is helpful if you are working on multiple projects that have different development standards.

Finally, you can place a Shared Standards file on a shared network drive and have all installations of Total Visual CodeTools use this file. Because this file can be password protected, you can define and protect standards from unwarranted modification.

The Total Visual CodeTools Shared Standards architecture is designed to be both easy to use and flexible. This section contains the information you need to get up and running in multiple situations.

Single Developer, Single Project

If you are a single developer using Total Visual CodeTools on a single project, you can start using the product immediately with the default Standards settings. However, it is worth the time to review the default values and adjust them according to your needs.

Single Developer, Multiple Projects

If you are a single developer working on multiple projects, you can use multiple Shared Standards files to accommodate the different requirements for each project. For example, you have a client who requires a particular type of commenting, while another requires a specific error handling format.

Multiple Developers, Connected to the Same Network

In this scenario, you have multiple developers who are connected to the same network or shared drive. Each developer has an installation of Total Visual CodeTools and you want to configure Shared Standards so every developer uses the same settings. To accomplish this, you must first configure the Shared Standards file, and then configure each installation of Total Visual CodeTools to use the same Shared Standards file.

Working in Disconnected Environments

Having all developers working with Total Visual CodeTools using a shared settings file is a great concept. But what happens when a developer disconnects his or her computer from the network? Developers often go offsite with mobile computers. What happens to the connection to the settings file in such a case?

To handle this scenario, Total Visual CodeTools automatically checks at startup to see if its connection to the Shared Settings file is available. If not, it automatically switches to a local copy. This means that Total Visual CodeTools can be used even when disconnected from a Shared Settings file located on a shared drive.

The next time the disconnected developer connects to the shared drive and starts Total Visual CodeTools, the program automatically reconnects to the Shared Settings file on the shared drive.

Note that if you have assigned a settings file to the Shared Settings file, and a developer is working in disconnected mode, the developer will not be able to change any settings--this is the design of password protection. However, the developer, who may be at a remote site, may need to change certain settings in response to project requirements. In such a case, the developer can clear the password on his or her local copy using the Save As feature. See the following section on Password Protection for more information.

This section covers the management aspects of Shared Standards files, including password-protection, making backups, and restoring defaults.

Password-Protecting Shared Standards Files

In order to protect against unwanted changes to your standards, you can assign a password to Shared Standards files. By assigning a password, you are restricting certain values in the Standards form to be read-only, unless you have a password. This is not so much a security feature as it is a convenience feature. Even if you assign a password to a Shared Settings file, there is nothing to stop a developer from point to any other (non-password-protected) settings file. Instead, the password-protection feature is designed to prevent developers from making unintentional changes to the team or enterprise standards already defined.

Making Backups of Shared Standards Files

Because Shared Standards files contain a lot of information, recreating them manually in the event of a system failure would be a time-consuming process. To prevent this from happening, it is a good idea to make backups of your Shared Standards files. To do this, simply copy any .CTS files to your backup media.

Restoring Defaults

At any time, you can restore the current Shared Settings file to its default values by pressing the [Defaults] button at the bottom of the Standards form. Because this action overwrites any current values, you should use the [Save As] button (under Manage Settings) to save your current settings before restoring defaults.