▪Do not waste time laying out statements in the metadata section in a particular way if you are using UNICOM Intelligence Professional. The mrScriptMetadata DSC that reads the .mdd file reformats the metadata section each time it opens a file.

▪Statements in the routing section may be split across lines as long as each line except the last ends with an underscore symbol.

▪Unless unbounded, or containing a very large number of iterations, include the expand keyword in all grid and loop definitions.

▪Make questions and information items names reflect the purpose or content of the question or item.

▪Avoid names that are the same as or very similar to interview scripting keywords.

▪Give questions and other items mixed case names.

▪Define unique response names for the special Other, No Answer, Don't Know, and Refuse to Answer responses rather than using a dash (–). Using a dash generates a response whose name matches the special keyword, and this is unlikely to be unique within the script as a whole.

▪Do not include special responses such as other or na, or response ordering keywords such as rot or ran in shared lists unless you want these responses and settings to apply every time the list is used.

▪In multiple-language projects, use info statements in the metadata section of the script for all non-question text that requires translation. Any text that exists in the routing section cannot be translated and will always be displayed in the questionnaire’s base language. This is particularly important for error messages.

▪When setting Initial text that should be replaced, put the text in brackets; for example, “<Type your answer here>”.

▪If style, validation, and response constants apply to all routing contexts, set them in the metadata section. For example, default values for questions typically apply to all routing contexts, so should be set in the metadata section. Conversely, some styles may only apply to a specific routing context, so should be set in that context in the routing section.

▪In scripts that copy information between the interview and the sample record, use similar names for questions and sample fields that are related. For example, if the Age sample field contains the participant’s age you might call the question in the script QAge. Alternatively, you might decide to give all sample fields names that start with “Sample”, so the Age question in the script could refer to the SampleAge field in the sample record. If your script has sample quotas, you may want to use identical names for questions and sample fields. For more information, see Sample quotas when you have No Access to the sample database.

▪Use indentation and blank lines to make the structure of the section easy to follow. (When working in UNICOM Intelligence Professional, you may indent using tabs but select the option that converts tabs to spaces to ensure a smooth transition to other tools.)

▪Give temporary (Dim’d) variables lower-case names and place these declarations at the top of the routing section.

▪Give constants upper-case names.

▪Use comments to explain complex code blocks: see Comments.

▪Use the curly brace notation when referring to categorical values rather than enclosing values in double quotation marks; for example:

▪Use category names rather than indexes when referring to categorical values as this makes scripts easier to read. For example, in a loop called Color in which red is the fourth item in the loop control list, use If (Color[{Red}].Likes.Response = {No}) rather than If (Color[3].Likes.Response = {No}) to test whether the respondent likes red.

▪Use If...Then with End If rather than using the single-line syntax.

▪Start all label names (used for Gotos) in column 1.

▪Start Sub and Function declarations and Ends in column 1, but indent their contents.

▪It is easy to create infinite loops when using Goto, so consider replacing Goto with an If statement with the appropriate condition. For example, rather than:

▪Always type object references in full. Object references can often be abbreviated by assuming that default properties will be used wherever a property name is not defined. However, this is bad programming practice and should be avoided, especially when writing interview scripts that other people may work on. For example, use Q1.Response.Categories[{Other}] instead of Q1.Response.Other since the latter can be used only if the category is named Other. The exceptions are Item and Value so, for example, use Q1.Response rather than Q1.Response.Value.

▪Put JavaScript in separate .js files and use an <mrRef> tag to include them in the template file.

▪When writing a loop where the number of repetitions is controlled by the response to a numeric question, define the number of repetitions in full rather than using the abbreviated [..variable_name] notation. Loops defined using this notation use a lower boundary of 0 which means that the loop will be repeated one more time than you will normally require. In addition, always ensure that you define a start value that is greater than 0 otherwise the same problem will arise. For example, if you write:

▪Try to define default styles in a template or cascading stylesheet rather than using the DefaultStyles object.

▪When a series of routing statements applies to the same object, for example, you are defining a number of styles for the same question, use a With statement to define the portion of code that is common to all statements rather than typing each statement in full. For example:

▪Use a single For Each statement rather than [..] when setting more than one property in a collection, as each instance of [..] is equivalent to a For Each statement. For example:

▪Use custom validation functions to avoid using Goto statements. For example, in the following example, a Goto statement is used to re-ask the question if the constant sum validation fails:

▪Use Enums instead of numeric values or string literals to improve readability. For example, use TerminateStatus.tsScriptStopped instead of 1.

▪Do not ask questions within Functions or Subs as restarts will not work correctly if they were to occur on the following question; the script in the Function or Sub after the ask statement will not be executed. The only exception to this rule is when the .Ask() statement is the last statement executed in a Sub; only a single question or page can be asked. For example, the following is acceptable:

▪When MyQuestion is a variable (not known in advance), use name-based look-up into collections to avoid linear searches:

▪Use IsNullObject to check if an object is NULL. Comparing an object to NULL will return True if the default property of the object returns NULL. Using IsNullObject checks to see if the object is NULL without expanding the default property. For more information, see IsNullObject.

▪Use FindItem to search for an item in a collection that may or may not exist. FindItem uses name-based look-up into collections. For more information, see FindItem.

▪Templates should meet XHTML standards; in particular, all tags should be written in lower case and each opening tag should have a closing tag.

▪Default templates should use a cascading style sheet.

▪Default templates should use relative fonts.

▪Define layout characteristics as styles in the metadata section rather than in the routing section or in templates if you want them to carry forward into other products such as UNICOM Intelligence Reporter - Survey Tabulation or UNICOM Intelligence Reporter.