EAC Decision on Request for Interpretation 2010-02

2005 VVSG Vol. I, Section, 5.2.3 d 

2005 VVSG Vol. I, Section, 5.2.5 

2005 VVSG Vol. I, Section, 5.2.6 

2005 VVSG Vol. I, Section, 5.2.7 b, c, d & e 

2005 VVSG Vol. II, Section, 5.4.2 

Date: 

May 25, 2010 

Question(s): 

For any given language implemented by a vendor, is there a limit to the number of coding 

conventions that can be referenced for that language? 

If the manufacturer chooses to use a coding standard other than the VVSG 2005 are they 

then exempt from the coding standards in Volume I and Volume II? 

Sections of Standards or Guidelines: 

5.2.3 Software Modularity and Programming 

Voting system application software, including commercial off-the-shelf (COTS) 

software, shall be designed in a modular fashion. However, COTS software is not 

required to be inspected for compliance with this requirement. For the purpose of this 

requirement1, “modules” may be compiled or interpreted independently. Modules may 

also be nested. The modularity rules described here apply to the component sub-modules 

of a library. The principle to be followed is that the module contains all the elements to 

compile or interpret successfully and has limited access to data in other modules. The 

design concept is simple replacement with another module whose interfaces match the 

original module. A module is designed in accordance with the rules below. 

d. A module is small enough to be easy to follow and understand. Program logic 

visible on a single page is easy to follow and correct. Volume II, Section 5 

provides testing guidelines for the accredited test lab to identify large modules 

subject to review under this requirement. 

5.2.5 Naming Conventions 

Voting system software shall use the naming conventions below. 

a. Object, function, procedure, and variable names shall be chosen to enhance the 

readability and intelligibility of the program. Insofar as possible, names shall be 
2

selected so that their parts of speech represent their use, such as nouns to 

represent objects and verbs to represent functions. 

b. Names used in code and in documentation shall be consistent. 

c. Names shall be unique within an application. Names shall differ by more than a 

single character. All single-character names are forbidden except those for 

variables used as loop indexes. In large systems where subsystems tend to be 

developed independently, duplicate names may be used where the scope of the 

name is unique within the application. Names should always be unique where 

modules are shared. 

d. Language keywords shall not be used as names of objects, functions, procedures, 

variables or in any manner not consistent with the design of the language. 

5.2.6 Coding Conventions 

Voting system software shall adhere to basic coding conventions. The coding 

conventions used shall meet one of the following conditions: 

a. The vendors shall identify the published, reviewed, and industry-accepted coding 

conventions used and the accredited test lab shall test for compliance 

b. The accredited test lab shall evaluate the code using the coding convention 

requirements specified in Volume II, Section 5 

These guidelines reference conventions that protect the integrity and security of the code, 

which may be language-specific and language-independent conventions that significantly 

contribute to readability and maintainability. Specific style conventions that support 

economical testing are not binding unless adopted by the vendor. 

5.2.7 Comment Conventions 

Voting system software shall use the following comment conventions: 

b. Descriptive comments shall be provided to identify objects and data types. All 

variables shall have comments at the point of declaration clearly explaining their 

use. Where multiple variables that share the same meaning are required, the 

variables may share the same comment 

c. In-line comments shall be provided to facilitate interpretation of functional 

operations, tests, and branching 

d. Assembly code shall contain descriptive and informative comments such that its 

executable lines can be clearly understood 

e. All comments shall be formatted in a uniform manner that makes it easy to 

distinguish them from executable code 

Conclusion: 

There are two clarifications to Volume I Section 5.2.6. First, the standard is to be read as 

an “or” statement. This interpretation means that the manufacturer must satisfy either “a” 

or “b”. Second, for part “a” a manufacturer may choose the industry-accepted coding 

standard to apply to their selected programming language assuming it meets the VVSG. 

The plural “conventions” is interpreted to mean that the manufacturer may have multiple 
3

coding conventions due to different programming languages being implemented. 

However, the manufacturer may only use one coding convention per language. 

If a manufacturer chooses to use a coding standard that meets the requirement of Volume 

I Section 5.2.6.a, they shall then be exempt from Volume I Sections 5.2.3 d, 5.2.5, 5.2.7 

b, c, d, and e, and Volume II section 5.4.2. 

Effective Date: 

For all systems without an approved system application