The flexibility DESTINI Estimator offers is both refreshing and exciting. The estimating software allows users to customize how data is managed and used to produce deliverables. However, this flexibility can be perilous. With an open-ended naming convention for formulaic placeholders, a database can become cluttered with names of varying format, length, and convention. This can lead to difficulty for end-users in understanding how the results are generated and for the data manager(s) to easily navigate, manage, and troubleshoot the back-end of the estimating database.
For those reasons, the following suggestions are below.
Database Element Naming Conventions
An effective estimating database, like any computer software, gains significant power and efficiency from the use of Variables and pre-programmed formulas called Formulas in this case. Variables, just like in mathematics, are a placeholder within a formula. There are three variables in Pythagorean’s Theorem: a, b, and c.
In order to be inserted as a Formula in the estimating database, the theorem itself would need to be rearranged so that the result is an unmodified variable as follows:
In this way, c is now a result and a and b are the only variables. This new function can be considered a Formula.
Because the estimating database is going to have a plethora of variables to address a multitude of conditions, using single letters as in mathematical expressions is not advantageous. Management of the database and troubleshooting are additional concerns to address in the development and maintenance of Variables and Formulas. The main objective in naming a Variable or Function is to identify what the placeholder represents and its application.
For example: let’s use the adjusted Pythagorean Theorem from earlier to calculate the length of a steel shape needed to install as a bracing element in a steel-framed bay.
From this example, we can clearly determine what is being measured (variables) and what it produces (formula result). But this simple expression is now taking up much more screen space than the original. And as formulas for construction elements are much more complicated than a two-variable input, adding many more variables to a Formula when the names of the variables are in sentence form can become unnecessarily hard to follow and manage.
For this reason, a standardized method in which Variables and Formulas are named should be adopted. Not only to describe what the ‘real’ element is, but also what kind of placeholder is represented by the placeholder.
Naming standard for Variables:
- Must start with a letter.
- Written in all lowercase.
- No spaces or symbols.
- Only Units of Measure are abbreviated.
- The least number of distinct words needed to describe the element:
- One noun to describe the physical object
- One noun to describe the measurable element
- No prepositions (‘at’, ‘is’, etc.).
- Attempt to limit suffixes unless it explicitly describes the element (-ing, -ed, -est).
*It should be noted here that Project Properties are treated as variables in the back-end of Estimator and thereby could follow the same convention. However, from a database management standpoint, this becomes a less desirable method of easily ascertaining where a given placeholder is located and how the user interacts with it. For this reason, Project Properties should be given the same naming standards with one exception: Capitalize Each Word. In this way, "Number of Floors" becomes FloorsCount or simply Floors.
Naming standard for Formulas:
Similar to the Variable naming convention but it starts with "FX_". For example, "FX_bracelength".
Naming standard for Choices:
Similar to the Variable naming convention but it starts with "CH_". For example, "CH_choicename".
Naming standard for Questions:
Similar to the Variable naming convention but it starts with "QU_". For example, "QU_questionname".
This allows the user/viewer to distinguish between variables and formulas when a string of variables and formulas are nested together: i.e. IF(rebarpremium=1, FX_SOG_Reinforcement,0).
