executable statement

executable statement

[‚ek·sə′kyüd·ə·bəl ′stāt·mənt]
(computer science)
A program statement that causes the computer to carry out some operation, in contrast to a declarative statement.
References in periodicals archive ?
[6] to calculate the suspiciousness of each executable statement as the detected priority.
Wong and Qi propose a back propagation (BP) neural network in [10], which utilizes the coverage data of test cases (e.g., the coverage data with respect to which statements are executed by which test case) and their corresponding execution results to train the network and, then, input the coverage of a set of virtual test cases (e.g., each test case covers only one statement) to the trained network, and the outputs are regarded as the suspiciousness (i.e., likelihood of containing the bug) of each executable statement. But the BP neural network leads to problems like local minima.
Suppose that there is a program P with m executable statements and n test cases to be executed, [t.sub.i] denotes the ith test case, while vectors [mathematical expression not reproducible], represent the corresponding coverage data and execution result, respectively, after executing the test case [t.sub.i], and [s.sub.j] is jth executable statement of program P.
In the set of virtual test cases, the test case [v.sub.j] only covers executable statement [s.sub.j].
They tested the impact of module size and strength (cohesion) on programming effort, measured as programmer hours per executable statement. They found that effort decreased as the size of the module increased.
The first metric is the average size in executable statements of a module's procedures (PROCSIZE).
Module length, in executable statements (MODLSIZE) was selected as the metric of module-level modularity [5].(3) The effect of this complexity metric is expected to depend on the application systems being analyzed.
In the current research the initial candidate metric chosen for branching was the proportion of the executable statements that were GOTO statements (GOTOSTMT).
Malicious codes (logic programs that contain executable statements) take various forms, including viruses, Trojan horses, worms and or logic bombs.
Results show that comparing with metrics such as Lines of code (LOC) and Cyclomatic complexity (V(G)) which are traditionally used for risk prediction, Halstead program difficulty (D), Number of executable statements (EXEC) and Halstead program volume (V) are the more effective metrics as risk predictors.
It was found when comparing with extracted metrics such as Lines of code (LOC) and Cyclomatic complexity (V(G)) which were traditionally used for risk prediction [8], [9] in this kind of software systems, Halstead program difficulty (D), Number of executable statements (EXEC) and Halstead program volume (V) were more useful.
Description: A count of the number of executable statements in the function.