Configuration - Keep Your Files Tidy!

When your configuration file is only a few lines long and can be taken in at a glance, how it is set out may not be that important. However once you get into configuration and the files grow, being tidy makes life a lot easier.

Some guidelines:

  • Use comments - the reason for adding some statements may no longer be obvious or remembered 18 months later.

  • Break your file down into sections with consistent headings - this helps with legibility, e.g.:

# User Settings

  • Maintain a revision history, and for longer files, a table of contents in the header.
    For example, a reasonably sophisticated and well commented Standards.cfg (hopefully renamed <CompanyName>_Standards.cfg) may be a few hundred lines long.

    A header like this can be very useful, the revision history tracks changes, the table of contents gives an idea of the extent and arrangement of the contents:

# <CompanyName> Bentley V8i standards.cfg - 29 July 2012
# v 0.3 Minor updates 24 Sept 2012
# v 0.2 $(MSDIR)mdlsys/textures/ commented out paths removed, the defaults point to this location. 17 Sept 2012
# v 0.1 Initial Wip for testing in new workspace
# Contents:
# Custom variables
# User Settings
# Spelling
# Site Resource Files, Settings and Data Files
# Operational Settings
# Output
# Reference Settings
# Raster settings
# Seed Files
# Libraries
# Levels
# VBA and MDL Applications
# Cells
# Design History
# Printing
# Rendering

  • Great series on ABD config files. They're great for beginning users. This offers great advise for non-programmers who might not be aware of documenting their code.

    One of the great things about Microstation are the config files. But they can be daunting for the uninitiated. And, coming from a source inside Bentley these articles have authority. They can become a standard as such. One thing I'd love to see is a script that offered a administrator the chance to define his own names and folders, the make the changes automatically. That would make setup a breeze for newbees.

    More specific to this blog, I'd like to offer an additional suggestion for documenting config files. We bracket version history at the point of modification as well. Something like:

    ## BEGIN MODIFICATION, Tom MacKnight, 22Jan2014, v2014.2

    ... config lines here

    ## END MODIFICATION, Tom MacKnight, 22Jan2014,  v2014.2

    This way we can scroll through the file and more easily locate version changes. We can also do a text search. While we add our own header to config files, we leave any Bentley provided header so we can trace the original source. It is our practice to seldom delete lines, but comment the lines that we change. This is especially true for the original source lines from Bentley.  Again, that adds traceability to the changes.