computer science corporation

 computer science corporation

2. Basics 

The flow of control (or simply control flow) is how a program processes its instructions.Typically, programs operate in a linear or sequential flow of control. Executable statementsor instructions in a program are performed one after another. In source code, the orderthat instructions are written defines their order. Just like English, a program is “read”top to bottom. Each statement may modify the state of a program. The state of aprogram is the value of all its variables and other information/data stored in memoryat a given moment during its execution. Further, an executable statement may insteadinvoke (or call or execute) another procedure (also called subroutine, function, method,etc.) which is another unit of code that has been encapsulated into one unit so that itcan be reused.

This type of control flow is usually associated with a procedural programming paradigm(which is closely related to imperative or structured programming paradigms). Thoughthis text will mostly focus on languages that are procedural (or that have strong proceduralaspects), it is important to understand that there are other programming languageparadigms. Functional programming languages such as Scheme and Haskell achievecomputation through the evaluation of mathematical functions with as little or no (“pure”functional) state at all. Declarative languages such as those used in database languageslike SQL or in spreadsheets like Excel specify computation by expressing the logic ofcomputation rather than explicitly specifying control flow. For a more formal introductionto programming language paradigms, a good resource is Seven Languages in Seven Weeks:A Pragmatic Guide to Learning Programming Languages by Tate [36]. 

2.1.1. Flowcharts 

Sometimes processes are described using diagrams called flowcharts. A flowchart is avisual representation of an algorithm or process consisting of boxes or “nodes” connectedby directed edges. Boxes can represent an individual step or a decision to be made. Theedges establish an order of operations in the diagram.Some boxes represent decisions to be made which may have one or more alternate routes(more than one directed edge going out of the box) depending on the the result of the

Figure 2.1.: Types of Flowchart Nodes. Control and action nodes are distinguishedby color. Control nodes are automated steps while action nodes are stepsperformed as part of the algorithm being depicted.

decision. Decision boxes are usually depicted with a diamond shaped box.

Other boxes represent a process, operation, or action to be performed. Boxes representinga process are usually rectangles. We will further distinguish two types of processes usingtwo different colorings: we’ll use green to represent boxes that are steps directly relatedto the algorithm being depicted. We’ll use blue for actions that are necessary to thecontrol flow of the algorithm such as assigning a value to a variable or incrementing avalue as part of a loop. Figure 2.1 depicts the three types of boxes we’ll use. Figure 2.2depicts a simple ATM (Automated Teller Machine) process as an example. 

2.2. Variables

In mathematics, variables are used as placeholders for values that aren’t necessarilyknown. For example, in the equation, 

×= 3y+5 

the variables x and y represent numbers that can take on a number of different values.Similarly, in a computer program, we also use variables to store values. A variable isessentially a memory location in which a value can be stored. Typically, a variable isreferred to by a name or identifier (like x, y, z in mathematics). In mathematics variablesare usually used to hold numerical values. However, in programming, variables canusually hold different types of values such as numbers, strings (a collection of characters),Booleans (true or false values), or more complex types such as arrays or objects.

Example of a flowchart for a simple ATM process 

2.2.1. Naming Rules & Conventions 

Most programming languages have very specific rules as to what you can use as variableidentifiers (names). For example, most programming languages do not allow you to usewhitespace characters (space, tab, etc.) in a variable’s identifier. Allowing spaces wouldmake variable names ambiguous: where does the variable’s name end and the rest of theprogram continue? How could you tell the difference between “average score” and twoseparate variables named “average” and “score”? Many programming languages alsohave reserved words–words or terms that are used by the programming language itselfand have special meaning. Variable names cannot be the same as any reserved word asthe language wouldn’t be able to distinguish between them. 

For similar reasons, many programming languages do not allow you to start a variablename with a number as it would make it more difficult for a compiler or interpreter toparse a program’s source code. Yet other languages require that variables begin with aspecific character (PHP for example requires that all variables begin with a dollar sign,$ ). 

In general, most programming languages allow you to use a combination of uppercaseA-Z and lowercase a-z letters as well as numbers, [0-9] and certain special characterssuch as underscores _ or dollar signs, $ . Moreover, most programming languages (likeEnglish) are case sensitive meaning that a variable name using lowercase letters is notthe same variable as one that uses uppercase letters. For example, the variables x andX are different; the variables average , Average and AVERAGE are all different as well.A few languages are case-insensitive meaning that they do not recognize differences inlower and uppercase letters when used in variable identifiers. Even in these languages, 

2. Basicshowever, using a mixture of lowercase and uppercase letters to refer to the same variableis discouraged: it is difficult to read, inconsistent, and just plain ugly.Beyond the naming rules that languages may enforce, most languages have establishednaming conventions; a set of guidelines and best-practices for choosing identifier namesfor variables (as well as functions, methods, and class names). Conventions may bewidely adopted on a per-language basis or may be established within a certain library,framework or by an organization that may have official style guides. Naming conventionsare intended to give source code consistency which ultimately improves readability andmakes it easier to understand. Following a consistent convention can also greatly reducethe chance for errors and mistakes. Good naming conventions also has an aestheticappeal; code should be beautiful. 

There are several general conventions when it comes to variables. An early convention,but still in common use is underscore casing in which variable names consisting of morethan one word have words separated by underscore characters with all other charactersbeing lowercase. For example: 

A variation on this convention is to use all uppercase letters such as MILES_PER_HOUR .A more modern convention is to use lower camel casing (or just camel casing) in whichvariable names with multiple words are written as one long word with the first letter ineach new word capitalized but with the first word’s first letter lowercase. For example: 

The convention refers to the capitalized letters resembling the humps of a camel. Oneadvantage that camel casing has over underscore casing is that you’re not always strainingto type the underscore character. Yet another similar convention is upper camel casing,also known as PascalCase1 which is like camel casing, but the first letter in the first wordis also capitalized: 

Each of these conventions is used in various languages in different contexts which we’llexplore more fully in subsequent sections (usually underscore lowercasing and camelcasing are used to denote variables and functions, PascalCase is used to denote userdefined types such as classes or structures, and underscore uppercasing is used to denotestatic and constant variables). However, for our purposes, we’ll use lower camel casingfor variables in our pseudocode. 

There are exceptions and special cases to each of these conventions such as when a variablename involves an acronym or a hyphenated word, etc. In such cases sensible extensions orcompromises are employed. For example, xmlString or priorityXMLParser (involvingthe acronym Extensible Markup Language (XML)) may be used which keep all letters inthe acronym consistent (all lowercase or all uppercase). 

In addition to these conventions, there are several best-practice principles when decidingon identifiers.

Be descriptive, but not verbose – Use variable names that describe what thevariable represents. The examples above, averageScore , numberOfStudents ,milesPerHour clearly indicate what the variable is intended to represent. Usinggood, descriptive names makes it your code self-documenting (a reader can makesense of it without having to read extensive supplemental documentation). 

Avoid meaningless variable names such as value , aVariable , or some crypticcombination of v10 (its the 10th variable I’ve used!). Ambiguous variables suchas name should also be avoided unless the context makes its clear what you arereferring to (as when used inside of a Person object). 

Single character variables are commonly used, but used in a context in which theirmeaning is clearly understood. For example, variable names such as x , y are okayif they are used to refer to points in the Euclidean plane. Single character variablessuch as i , j are often used as index variables when iterating over arrays. In thiscase, terseness is valued over descriptiveness as the context is very well understood.

As a general rule, the more a variable is used, the shorter it should be. Forexample, the variable numStudents may be preferred over the full variablenumberOfStudents .

Avoid abbreviations (or at least use them sparingly) – You’re not being charged bythe character in your code; you can afford to write out full words. Abbreviations canhelp to write shorter variable names, but not all abbreviations are the same. Theword “abbreviation” itself could be abbreviated as “abbr.”, “abbrv.” or “abbrev.”for example. Abbreviations are not always universally understood by all users,may be ambiguous and non-standard. Moreover, modern IDEs provide automaticcode completion, relieving you of the need to type longer variable names. If theabbreviation is well-known or understood from context, then it may make sense touse it. 

Avoid acronyms (or at least use them sparingly) – Using acronyms in variablenames come with many of the same problems as abbreviations. However, if it makessense in the context of your code and has little chance of being misunderstood ormistaken, then go for it. For example, in the context of a financial application,APR (Annual Percentage Rate) would be a well-understood acronym in which case 

the variable apr may be preferred over the longer annualPercentageRate .• Avoid pluralizations, use singular forms – English is not a very consistent languagewhen it comes to rules like pluralizations. For most cases you simply add “s”; forothers you add “es” or change the “y” to “i” and add “es”. Some words are thesame form for singular and plural such as “glasses.”2 Other words have completelydifferent forms (“focus” becomes “foci”). Still yet there are instances in whichmultiple words are acceptable: the plural of “person” can be “persons” or “people”.Avoiding plural forms keeps things simple and consistent: you don’t need to bea grammarian in order easily read code. One potential exception to this is whenusing a collection such as an array to hold more than one element or the variablerepresents a quantity that is pluralized (as with numberOfStudents above). 

Though the guidelines above provide a good framework from which to write good variablenames, reasonable people can and do disagree on best practice because at some point asyou go from generalities to specifics, conventions become more of a matter of personalpreference and subjective aesthetics. Sometimes an organization may establish its owncoding standards or style guide that must be followed which of course trumps any of theguidelines above. 

In the end, a good balance must be struck between readability and consistency. Rulesand conventions should be followed, until they get in the way of good code that is.