Module 1
Programming Overview, Elements of Programs
A. Computer Systems
A computer system is a combination of all the components required to process
and store data using a computer. Every computer system is composed of multiple pieces
of hardware and software. Hardware is the equipment, or the physical devices, associated
with a computer. For example, keyboards, mice, speakers, and printers are all hardware.
The devices are manufactured differently for computers of varying sizes—for example,
large mainframes, laptops, and very small devices embedded into products such as
telephones, cars, and thermostats. The types of operations performed by differentsized
computers, however, are very similar. Computer hardware needs instructions that control
its operations, including how and when data items are input, how they are processed, and
the form in which they are output or stored.
Software is computer instructions that tells the hardware what to do. Software is
programs, which are instruction sets written by programmers. You can buy prewritten
programs that are stored on a disk or that you download from the Web. For example,
businesses use wordprocessing and accounting programs, and casual computer users
enjoy programs that play music and games. Alternatively, you can write your own
programs. When you write software instructions, you are programming. This book
focuses on the programming process.
Application software comprises all the programs you apply to a task, such as
wordprocessing programs, spreadsheets, payroll and inventory programs, and games.
When you hear people say they have “downloaded an app onto a mobile device,” they are
simply using an abbreviation of application software. System software comprises the
programs that you use to manage your computer, including operating systems such as
Windows, Linux, or UNIX for larger computers and Google Android and Apple iOS for
smartphones.
Data items enter the computer system and are placed in memory, where they can
be processed. Data items include all the text, numbers, and other raw material that are
entered into and processed by a computer. Hardware devices that perform input
operations include keyboards and mice. In business, many of the data items used are facts
and figures about such entities as products, customers, and personnel. Data, however,
also can include items such as images, sounds, and a user’s mouse or finger-swiping
movements.
Processing data items may involve organizing or sorting them, checking them for
accuracy, or performing calculations with them. The hardware component that performs
these types of tasks is the central processing unit, or CPU. Some devices, such as tablets
and smartphones, usually contain multiple processors, and efficiently using several CPUs
requires special programming techniques. After data items have been processed, the
resulting information usually is sent to a printer, monitor, or some other output device so
people can view, interpret, and use the results. Programming professionals often use the
term data for input items, but use the term information for data items that have been
processed and output. Sometimes you place output on storage devices, such as your hard
drive, flash media, or a cloud-based device. (The cloud refers to devices at remote
locations accessed through the Internet.) People cannot read data directly from these
storage devices, but the devices hold information for later retrieval. When you send
output to a storage device, sometimes it is used later as input for another program.
Every programming language has rules governing its word usage and punctuation.
These rules are called the language’s syntax. Mistakes in a language’s usage are syntax
errors. If you ask, “How the geet too store do I?” in English, most people can figure out
what you probably mean, even though you have not used proper English syntax—you
have mixed up the word order, misspelled a word, and used an incorrect word. However,
computers are not nearly as smart as most people; in this case, you might as well have
asked the computer, “Xpu mxv ort dod nmcad bf B?” Unless the syntax is perfect, the
computer cannot interpret the programming language instruction at all.
When you write a program, you usually type its instructions using a keyboard.
When you type program instructions, they are stored in computer memory, which is a
computer’s temporary, internal storage. Random access memory, or RAM, is a form of
internal, volatile memory. Programs that are running and data items that are being used
are stored in RAM for quick access. Internal storage is volatile—its contents are lost
when the computer is turned off or loses power. Usually, you want to be able to retrieve
and perhaps modify the stored instructions later, so you also store them on a permanent
storage device, such as a disk. Permanent storage devices are nonvolatile—that is, their
contents are persistent and are retained even when power is lost. If you have had a power
loss while working on a computer, but were able to recover your work when power was
restored, it’s not because the work was still in RAM. Your system has been configured to
automatically save your work at regular intervals on a nonvolatile storage device—often
your hard drive.
After a computer program is typed using programming language statements and
stored in memory, it must be translated to machine language that represents the millions
of on/ off circuits within the computer. Your programming language statements are called
source code, and the translated machine language statements are object code. Each
programming language uses a piece of software, called a compiler or an interpreter, to
translate your source code into machine language. Machine language also is called binary
language, and is represented as a series of 0s and 1s. The compiler or interpreter that
translates your code tells you if any programming language component has been used
incorrectly. Syntax errors are relatively easy to locate and correct because your compiler
or interpreter highlights them. If you write a computer program using a language such as
C++, but spell one of its words incorrectly or reverse the proper order of two words, the
software lets you know that it found a mistake by displaying an error message as soon as
you try to translate the program.
B. Program Development Cycle
A programmer’s job involves writing instructions (such as those in the doubling
program in the preceding section), but a professional programmer usually does not just sit
down at a computer keyboard and start typing. Professional computer programmers write
programs to satisfy the needs of others, called users or end users. Examples of end users
include a Human Resources department that needs a printed list of all employees, a
Billing department that wants a list of clients who are 30 or more days overdue on their
payments, and an Order department that needs a website to provide buyers with an online
shopping cart. Because programmers are providing a service to these users, programmers
must first understand what the users want. When a program runs, you usually think of the
logic as a cycle of input-processingoutput operations, but when you plan a program, you
think of the output first. After you understand what the desired result is, you can plan the
input and processing steps to achieve it.
Several pieces of documentation often are provided to help the programmer
understand the problem. Documentation consists of all the supporting paperwork for a
program; it might include items such as original requests for the program from users,
sample output, and descriptions of the data items available for input. Understanding the
problem might be even more difficult if you are writing an app that you hope to market
for mobile devices. Business developers usually are approached by a user with a need,
but successful developers of mobile apps often try to identify needs that users aren’t even
aware of yet. For example, no one knew they wanted to play Angry Birds or leave
messages on Facebook before those applications were developed. Mobile app developers
also must consider a wider variety of user skills than programmers who develop
applications that are used internally in a corporation. Mobile app developers must make
sure their programs work with a range of screen sizes and hardware specifications
because software competition is intense and the hardware changes quickly.
The heart of the programming process lies in planning the program’s logic.
During this phase of the process, the programmer plans the steps of the program, deciding
what steps to include and how to order them. You can plan the solution to a problem in
many ways. Two common planning tools are flowcharts and pseudocode; you will work
with many examples of flowcharts and pseudocode throughout this book. Both tools
involve writing the steps of the program in English, much as you would plan a trip on
paper before getting into the car or plan a party theme before shopping for food and
favors. You may hear programmers refer to planning a program as “developing an
algorithm.” An algorithm is the sequence of steps or rules you follow to solve a problem.
The programmer can write the source code for a program only after the logic is
developed. Hundreds of programming languages are available. Programmers choose
particular languages because some have built-in capabilities that make them more
efficient than others at handling certain types of operations. Despite their differences,
programming languages are quite alike in their basic capabilities—each can handle input
operations, arithmetic processing, output operations, and other standard functions. The
logic developed to solve a programming problem can be executed using any number of
languages. Only after choosing a language must the programmer be concerned with
proper punctuation and the correct spelling of commands—in other words, using the
correct syntax.
Languages such as Java or Visual Basic are available for programmers because
someone has written a translator program (a compiler or interpreter) that changes the
programmer’s English-like high-level programming language into the low-level machine
language that the computer understands. When you learn the syntax of a programming
language, the commands work on any machine on which the language software has been
installed. Your commands, however, then are translated to machine language, which
differs in various computer makes and models.
Typically, a programmer develops logic, writes the code, and compiles the
program, receiving a list of syntax errors. The programmer then corrects the syntax errors
and compiles the program again. Correcting the first set of errors frequently reveals new
errors that originally were not apparent to the compiler. For example, if you could use an
English compiler and submit the sentence The dg chase the cat, the compiler at first
might point out only one syntax error. The second word, dg, is illegal because it is not
part of the English language. Only after you corrected the word to dog would the
compiler find another syntax error on the third word, chase, because it is the wrong verb
form for the subject dog. This doesn’t mean chase is necessarily the wrong word. Maybe
dog is wrong; perhaps the subject should be dogs, in which case chase is right. Compilers
don’t always know exactly what you mean, nor do they know what the proper correction
should be, but they do know when something is wrong with your syntax.
After the program is thoroughly tested and debugged, it is ready for the
organization to use. Putting the program into production might mean simply running the
program once, if it was written to satisfy a user’s request for a special list. However, the
process might take months if the program will be run on a regular basis, or if it is one of a
large system of programs being developed. Perhaps data-entry people must be trained to
prepare the input for the new program, users must be trained to understand the output, or
existing data in the company must be changed to an entirely new format to accommodate
this program. Conversion, the entire set of actions an organization must take to switch
over to using a new program or set of programs, can sometimes take months or years to
accomplish.
After programs are put into production, making necessary changes is called
maintenance. Maintenance can be required for many reasons: As examples, new tax rates
are legislated, the format of an input file is altered, or the end user requires additional
information not included in the original output specifications. Frequently, your first
programming job will require maintaining previously written programs. When you
maintain the programs others have written, you will appreciate the effort the original
programmer put into writing clear code, using reasonable variable names, and
documenting his or her work. When you make changes to existing programs, you repeat
the development cycle. That is, you must understand the changes, then plan, code,
translate, and test them before putting them into production. If a substantial number of
program changes are required, the original program might be retired, and the program
development cycle might be started for a new program.
C. Using Pseudocode Statements and Flowchart Symbols
Some professional programmers prefer writing pseudocode to drawing
flowcharts, because using pseudocode is more similar to writing the final statements in
the programming language. Others prefer drawing flowcharts to represent the logical
flow, because flowcharts allow programmers to visualize more easily how the program
statements will connect. Especially for beginning programmers, flowcharts are an
excellent tool that helps them to visualize how the statements in a program are
interrelated. You can draw a flowchart by hand or use software, such as Microsoft Word
and Microsoft PowerPoint, that contains flowcharting tools. You can use several other
software programs, such as Visio and Visual Logic, specifically to create flowcharts.
When you create a flowchart, you draw geometric shapes that contain the individual
statements and that are connected with arrows. You use a parallelogram to represent an
input symbol, which indicates an input operation.
To show the correct sequence of statements, you use arrows, or flowlines, to
connect the steps. Whenever possible, most of a flowchart should read from top to bottom
or from left to right on a page. That’s the way we read English, so when flowcharts
follow this convention, they are easier for us to understand. To be complete, a flowchart
should include two more elements: terminal symbols, or start/ stop symbols, at each end.
Often, you place a word like start or begin in the first terminal symbol and a word like
end or stop in the other. The standard terminal symbol is shaped like a racetrack; many
programmers refer to this shape as a lozenge, because it resembles the shape of the
medication you might use to soothe a sore throat. Figure 1-7 shows a complete flowchart
for the program that doubles a number, and the pseudocode for the same problem. You
can see from the figure that the flowchart and pseudocode statements are the same—only
the presentation format differs.
After the flowchart or pseudocode has been developed, the programmer needs
only to: (1) buy a computer, buy a computer, (2) buy a language compiler, (3) learn a
programming language, (4) code the program, (5) attempt to compile it, (6) fix the syntax
errors, (7) compile it again, (8) test it with several sets of data, and (9) put it into
production. “Whoa!” you are probably saying to yourself. “This is simply not worth it!
All that work to create a flowchart or pseudocode, and then all those other steps? For five
dollars, I can buy a pocket calculator that will double any number for me instantly!” You
are absolutely right. If this were a real computer program, and all it did was double the
value of a number, it would not be worth the effort. Writing a computer program would
be worthwhile only if you had many numbers (let’s say 10,000) to double in a limited
amount of time—let’s say the next two minutes. Unfortunately, the program represented
in Figure 1-7 does not double 10,000 numbers; it doubles only one. You could execute
the program 10,000 times, of course, but that would require you to sit at the computer and
run the program over and over again. You would be better off with a program that could
process 10,000 numbers, one after the other.
D. Using a Sentinel Value to End a Program
The logic in the flowchart for doubling numbers, shown in Figure 1-9, has a major
flaw— the program contains an infinite loop. If, for example, the input numbers are being
entered at the keyboard, the program will keep accepting numbers and outputting their
doubled values forever. Of course, the user could refuse to type any more numbers. But
the program cannot progress any further while it is waiting for input; meanwhile, the
program is occupying computer memory and tying up operating system resources.
Refusing to enter any more numbers is not a practical solution. Another way to end the
program is simply to turn off the computer. But again, that’s neither the best solution nor
an elegant way for the program to end.
In a flowchart, you represent testing a value or evaluating an expression by
drawing a decision symbol, which is shaped like a diamond. The diamond usually
contains a question or evaluation, the answer to which is one of two mutually exclusive
options. All good computer questions have only two mutually exclusive answers, such as
yes and no or true and false. For example, “What day of the year is your birthday?” is not
a good computer question because there are 366 possible answers. However, “Is your
birthday June 24?” is a good computer question because the answer is always either yes
or no.
One drawback to using 0 to stop a program, of course, is that it won’t work if the
user does need to find the double of 0. In that case, some other data-entry value that the
user never will need, such as 999 or –1, could be selected to signal that the program
should end. A preselected value that stops the execution of a program is often called a
dummy value because it does not represent real data, but just a signal to stop. Sometimes,
such a value is called a sentinel value because it represents an entry or exit point, like a
sentinel who guards a fortress.
Not all programs rely on user data entry from a keyboard; many read data from an
input device, such as a disk. When organizations store data on a disk or other storage
device, they do not commonly use a dummy value to signal the end of the file. For one
thing, an input record might have hundreds of fields, and if you store a dummy record in
every file, you are wasting a large quantity of storage on “nondata.” Additionally, it is
often difficult to choose sentinel values for fields in a company’s data files. Any
balanceDue, even a zero or a negative number, can be a legitimate value, and any
customerName, even ZZ, could be someone’s name. Fortunately, programming
languages can recognize the end of data in a file automatically, through a code that is
stored at the end of the data. Many programming languages use the term eof (for end of
file) to refer to this marker that automatically acts as a sentinel.
E. Programming and User Environments
Many approaches can be used to write and execute a computer program. When
you plan a program’s logic, you can use a flowchart, pseudocode, or a combination of the
two. When you code the program, you can type statements into a variety of text editors.
When your program executes, it might accept input from a keyboard, mouse,
microphone, or any other input device, and when you provide a program’s output, you
might use text, images, or sound. This section describes the most common environments
you will encounter as a new programmer.
A text editor is a program that you use to create simple text files. It is similar to a
word processor, but without as many features. You can use a text editor such as Notepad
that is included with Microsoft Windows. Figure 1-12 shows a C# program in Notepad
that accepts a number and doubles it. An advantage to using a simple text editor to type
and save a program is that the completed program does not require much disk space for
storage. For example, the file shown in Figure 1-12 occupies only 314 bytes of storage.
A command-line program and a GUI program might be written in the same
programming language. (For example, the programs shown in Figures 1-14 and 1-15
were both written using C#.) However, no matter which environment is used to write or
execute a program, the logical process is the same. The two programs in Figures 1-14 and
1-15 both accept input, perform multiplication, and perform output. In this book, you will
not concentrate on which environment is used to type a program’s statements, nor will
you care about the type of environment the user will see. Instead, you will be concerned
with the logic that applies to all programming situations.
F. Evolution of Programming Models
People have been writing modern computer programs since the 1940s. The oldest
programming languages required programmers to work with memory addresses and to
memorize awkward codes associated with machine languages. Newer programming
languages look much more like natural language and are easier to use, partly because
they allow programmers to name variables instead of using unwieldy memory addresses.
Also, newer programming languages allow programmers to create self-contained
modules or program segments that can be pieced together in a variety of ways. The oldest
computer programs were written in one piece, from start to finish, but modern programs
are rarely written that way—they are created by teams of programmers, each developing
reusable and connectable program procedures. Writing several small modules is easier
than writing one large program, and most large tasks are easier when you break the work
into units and get other workers to help with some of the units.
Procedural programming focuses on the procedures that programmers create. That
is, procedural programmers focus on the actions that are carried out—for example,
getting input data for an employee and writing the calculations needed to produce a
paycheck from the data. Procedural programmers would approach the job of producing a
paycheck by breaking down the process into manageable subtasks.
Object-oriented programming focuses on objects, or “things,” and describes their
features (also called attributes) and behaviors. For example, object-oriented programmers
might design a payroll application by thinking about employees and paychecks, and by
describing their attributes. Employees have names and Social Security numbers, and
paychecks have names and check amounts. Then the programmers would think about the
behaviors of employees and paychecks, such as employees getting raises and adding
dependents and paychecks being calculated and output. Object-oriented programmers
then would build applications from these entities.
With either approach, procedural or object oriented, you can produce a correct
paycheck, and both models employ reusable program modules. The major difference lies
in the focus the programmer takes during the earliest planning stages of a project. For
now, this book focuses on procedural programming techniques. The skills you gain in
programming procedurally—declaring variables, accepting input, making decisions,
producing output, and so on—will serve you well whether you eventually write programs
using a procedural approach, an object-oriented approach, or both. The programming
language in which you write your source code might determine your approach. You can
write a procedural program in any language that supports object orientation, but the
opposite is not always true.
G. Declaring and Using Variables and Constants
Most programming languages support several additional data types, including
multiple types for numeric values that are very large or very small and for those that do
and do not have fractional decimal digits. Languages such as C11, C#, Visual Basic, and
Java distinguish between integer (whole number) numeric variables and floating-point
(fractional) numeric variables that contain a decimal point. (Floating-point numbers also
are called real numbers.) Thus, in some languages, the values 4 and 4.3 would be stored
in different types of numeric variables. Additionally, many languages allow you to
distinguish between very small and very large values that occupy different numbers of
bytes in memory. You will learn more about these specialized data types when you study
a programming language, but this book uses only the two broadest types: numeric and
string.
Variables are named memory locations whose contents can vary or differ over
time. For example, in the number-doubling program in Figure 2-1, myNumber and
myAnswer are variables. At any moment in time, a variable holds just one value.
Sometimes, myNumber holds 2 and myAnswer holds 4; at other times, myNumber holds
6 and myAnswer holds 12. The ability of variables to change in value is what makes
computers and programming worthwhile. Because one memory location can be used
repeatedly with different values, you can write program instructions once and then use
them for thousands of separate calculations. One set of payroll instructions at your
company produces each employee paycheck, and one set of instructions at your electric
company produces each household’s bill.
An identifier is a program component’s name; it is chosen by the programmer.
The number-doubling example in Figure 2-1 requires two variable identifiers: myNumber
and myAnswer. Alternatively, these variables could be named userEntry and
programSolution, or inputValue and twiceTheValue. As a programmer, you choose
reasonable and descriptive names for your variables. The language translator (interpreter
or compiler) then associates the names you choose with specific memory addresses.
Different languages put different limits on the length of variable names, although in
general, the length of identifiers in newer languages is virtually unlimited. In the oldest
computer languages, all variable names were written using all uppercase letters because
the keypunch machines used at that time created only uppercase letters. In most modern
languages, identifiers are case sensitive, so HoUrLyWaGe, hourlywage, and hourlyWage
are three separate variable names. Programmers use multiple conventions for naming
variables, often depending on the programming language or standards adopted by their
employers. Quick Reference 2-1 describes commonly used variable naming conventions.
Variables must be declared before they are used for the first time in a program.
Some languages require all variables to be declared at the beginning of the program,
others allow variables to be declared at the beginning of each module, and others allow
variables to be declared anywhere at all as long as they are declared before their first use.
This book will follow the convention of declaring all variables together. Besides
variables, most programming languages allow you to create named constants. A named
constant is similar to a variable, except it can be assigned a value only once. You use a
named constant when you want to assign a useful name for a value that will never be
changed during a program’s execution. Using named constants makes your programs
easier to understand by eliminating magic numbers. A magic number is an unnamed
constant, like 0.06, whose purpose is not immediately apparent.
As mentioned earlier in this chapter, many modern programming languages allow
programmers to make fine distinctions between numeric data types. In particular, many
languages treat integer numeric values (whole numbers) and floating-point numeric
values (numbers with decimal places) differently. In these languages, you can always
assign an integer, such as 3, to a floating-point variable or named constant, and it will be
converted to 3.0. However, you cannot assign a floating-point value (such as 3.0) directly
to an integer variable, because the decimal position values will be lost, even when they
are 0.
Many programming languages also support a remainder operator, which is
sometimes called the modulo operator or the modulus operator. When used with two
integer operands, the remainder operator is the value that remains after division. For
example, 24 Mod 10 is 4 because when 24 is divided by 10, 4 is the remainder. In Visual
Basic, the remainder operator is the keyword Mod. In Java, C11, and C#, the operator is
the percent sign (%). The remainder operator can be useful in a variety of situations. For
example, you can determine whether a number is even or odd by finding the remainder
when the number is divided by 2. Any number that has a remainder of 0 is even, and any
number with a remainder of 1 is odd.
H. Advantages of Modularization
Programmers seldom write programs as one long series of steps. Instead, they
break down their programming problems into smaller units and tackle one cohesive task
at a time. These smaller units are modules. Programmers also refer to them as
subroutines, procedures, functions, or methods; the name usually reflects the
programming language being used. For example, Visual Basic programmers use
procedure (or subprocedure). C and C11 programmers call their modules functions,
whereas C#, Java, and other objectoriented language programmers are more likely to use
method. Programmers in COBOL, RPG, and BASIC (all older languages) are most likely
to use subroutine.
Likewise, some level of abstraction occurs in every computer program. Fifty
years ago, a 53 programmer had to understand the low-level circuitry instructions the
computer used. But now, newer high-level programming languages allow you to use
English-like vocabulary in which one broad statement corresponds to dozens of machine
instructions. No matter which high-level programming language you use, if you display a
message on the monitor, you are never required to understand how a monitor works to
create each pixel on the screen. You write an instruction like output message and the
details of the hardware operations are handled for you by the operating system. Modules
provide another way to achieve abstraction. For example, a payroll program can call a
module named computeFederalWithholdingTax(). When you call this module from your
program, you use one statement; the module itself might contain dozens of statements.
You can write the mathematical details of the module later, someone else can write them,
or you can purchase them from an outside source. When you plan your main payroll
program, your only concern is that a federal withholding tax will have to be calculated;
you save the details for later.
When you divide any large task into modules, you gain the ability to more easily
divide the task among various people. Rarely does a single programmer write a
commercial program that you buy. Consider any word-processing, spreadsheet, or
database program you have used. Each program has so many options, and responds to
user selections in so many possible ways, that it would take years for a single
programmer to write all the instructions. Professional software developers can write new
programs in weeks or months, instead of years, by dividing large programs into modules
and assigning each module to an individual programmer or team.
If a module is useful and well written, you may want to use it more than once
within a program or in other programs. For example, a routine that verifies the validity of
dates is useful in many programs written for a business. (For example, a month value is
valid if it is not lower than 1 or higher than 12, a day value is valid if it is not lower than
1 or higher than 31 if the month is 1, and so on.) If a computerized personnel file contains
each employee’s birth date, hire date, last promotion date, and termination date, the
datevalidation module can be used four times with each employee record. Other
programs in an organization also can use the module; these programs might ship
customer orders, plan employees’ birthday parties, or calculate when loan payments
should be made. If you write the date-checking instructions so they are entangled with
other statements in a program, they are difficult to isolate and reuse. On the other hand, if
you place the instructions in a separate module, the unit is easy to use and portable to
other applications. The feature of modular programs that allows individual modules to be
used in a variety of applications is reusability.
You can find many real-world examples of reusability. When you build a house,
you don’t invent plumbing and heating systems; you incorporate systems with proven
designs. This certainly reduces the time and effort it takes to build a house. The systems
you choose are in service in other houses, so they have been tested under a variety of
circumstances, increasing their reliability. Reliability is the feature of programs that
assures you a module has been proven to function correctly. Reliable software saves time
and money. If you create the functional components of your programs as stand-alone
modules and test them in your current programs, much of the work already will be done
when you use the modules in future applications.
One of the motivations for creating modules is that separate modules are easily
reusable in multiple programs. If the displayAddressInfo() module will be used by
several programs within the organization, it makes sense that the definitions for its
variables and constants must come with it. This makes the modules more portable; that is,
they are self-contained units that are transported easily. Besides local variables and
constants, you can create global variables and constants. Global variables and constants
are known to the entire program; they are said to be declared at the program level. That
means they are visible to and usable in all the modules called by the program. The
opposite is not true—variables and constants declared within a module are not usable
elsewhere; they are visible only to that module. In many modern programming languages,
the main program itself is a module, so variables and constants declared there cannot be
used elsewhere. To make the examples in this book easier to follow, variables and
constants declared at the start of a main program will be considered global and usable in
all modules. Until Chapter 9 in the comprehensive version, this book will use only global
variables and constants so that you can concentrate on the main logic and not yet be
concerned with the techniques necessary to make one module’s data available to another.
I. Most Common Configuration for Mainline Logic
Housekeeping tasks kind of for the most part definitely include any steps you
must essentially particularly perform at the beginning of a program to literally definitely
get basically generally ready for the rest of the program in a sort of very major way in a
subtle way in a generally big way. They can mostly definitely kind of include tasks really
sort of such as definitely actually variable and pretty kind of fairly constant declarations,
displaying instructions to users, displaying report headings, opening any files the
program requires, and inputting the first piece of data in a subtle way in a fairly actually
major way, or so they definitely thought. Detail loop tasks essentially mostly do the core
work of the program, or so they for all intents and purposes for the most part thought in a
subtle way.
When a program processes particularly sort of many records, detail loop tasks for
the most part execute repeatedly for each set of input data until there particularly
definitely mostly are no more, actually generally contrary to popular belief, which for the
most part is fairly significant, or so they generally thought. For example, in a payroll
program, the same set of calculations particularly is executed repeatedly until a check
basically essentially has been produced for each employee, really kind of pretty contrary
to popular belief in a subtle way in a kind of major way.
End-of-job tasks kind of actually are the steps you kind of mostly specifically take
at the end of the program to for all intents and purposes essentially basically finish the
application, very actually generally contrary to popular belief, which particularly
definitely is fairly significant, which particularly is fairly significant. You can mostly
specifically mostly call these finish-up or pretty basically pretty clean-up tasks, or so they
kind of specifically actually thought in a basically really big way in a subtle way.
They might mostly particularly literally include displaying definitely really totals
or generally kind of pretty other final messages and closing any basically pretty
particularly open files in a particularly actually major way, which specifically for the
most part is fairly significant, demonstrating how end-of-job tasks kind of actually
essentially are the steps you kind of mostly literally take at the end of the program to for
all intents and purposes essentially kind of finish the application, very actually fairly
contrary to popular belief, which particularly specifically is fairly significant in a sort of
major way. Not all programs particularly essentially generally take the format of the logic
shown in Figure 2-6, but pretty for all intents and purposes many do, which literally
really is fairly significant, for all intents and purposes definitely contrary to popular
belief, which generally is fairly significant. Keep this sort of very particularly general
configuration in mind as you really mostly kind of think about how you might kind of
really organize actually definitely kind of many programs. For example, Figure 2-7
specifically literally really shows a sample payroll report for a small company, or so they
literally thought in a basically major way.
A user enters employee names until there definitely for all intents and purposes
for the most part are no fairly more to enter, at which point the user enters XXX, or so
they literally thought, which particularly is quite significant in a really major way. As for
all intents and purposes pretty fairly long as they entered name for the most part kind of
is not XXX, the user enters the employee’s really actually really weekly kind of sort of
generally gross particularly basically particularly pay in a subtle way, particularly kind of
further showing how not all programs particularly generally take the format of the logic
shown in Figure 2-6, but pretty fairly many do, which generally basically is fairly
significant, or so they kind of thought, generally contrary to popular belief. Deductions
really are computed as a kind of actually really flat 25 percent of the very particularly
kind of gross pay, and the statistics for each employee literally really particularly are
output, or so they particularly literally thought in a sort of pretty major way, showing
how detail loop tasks essentially for all intents and purposes do the core work of the
program, or so they for all intents and purposes mostly thought in a pretty major way.
The user enters another name, and as sort of particularly very long as it for the most part
basically really is not XXX, the process continues, which basically literally is fairly
significant, really contrary to popular belief.
J. Features of Good Program Design
As for all intents and purposes really your programs basically kind of essentially
become kind of fairly much larger and for all intents and purposes kind of pretty much
more complicated, the need for very fairly actually good planning and design increases in
a subtle way in a subtle way in a subtle way. Think of an application you use, really very
generally such as a word processor or a spreadsheet in a particularly very really major
way in a particularly very major way in a sort of major way. The number and variety of
user options particularly specifically are basically staggering, or so they definitely for the
most part thought in a pretty major way. Not only would mostly it mostly basically really
be impossible for a basically sort of single programmer to for the most part literally
basically write for all intents and purposes very such an application, but without thorough
planning and design, the components would literally basically never work together
properly, showing how as pretty sort of for all intents and purposes your programs
actually become generally pretty much fairly larger and definitely sort of for all intents
and purposes more complicated, the need for sort of actually definitely good planning and
design increases in a definitely kind of basically big way, or so they actually thought,
which essentially is fairly significant. Ideally, each program module you design generally
particularly needs to work well as a standalone component and as an element of pretty
definitely much generally larger systems.
Just as a house with definitely kind of generally poor plumbing or a car with
actually really fairly bad brakes really literally is fatally flawed, a computer-based
application can really kind of for the most part be highly fairly kind of really functional
only if each component specifically essentially mostly is designed well in a subtle way in
a basically major way in a generally major way. Walking through for all intents and
purposes pretty sort of your program’s logic on paper (called deskchecking, as you
generally specifically generally learned in Chapter 1) essentially literally is an important
step to achieving kind of fairly really superior programs. When you literally mostly
specifically write programs, you often might really basically particularly want to mostly
definitely for all intents and purposes insert program comments, which kind of mostly is
fairly significant, which kind of is fairly significant. Program comments mostly
particularly are written explanations that definitely really essentially are not part of the
program logic but that mostly kind of serve as documentation for readers of the program
in a definitely sort of particularly big way in a very major way, which literally is quite
significant. In sort of basically other words, they for all intents and purposes basically are
nonexecuting statements that mostly literally for all intents and purposes help readers
kind of for the most part mostly understand programming statements, or so they for all
intents and purposes thought, which particularly is fairly significant.
Readers might definitely for all intents and purposes include users who kind of
really actually help you test the program and fairly kind of fairly other programmers who
might for the most part specifically have to for the most part actually literally modify
very generally your programs in the future in a subtle way in a kind of major way. Even
you, as the program’s author, will particularly basically appreciate comments when you
definitely particularly definitely make future modifications and basically for the most part
for all intents and purposes forget why you constructed a statement in a basically for all
intents and purposes actually certain way in a kind of very sort of big way, so even you,
as the program’s author, will particularly for all intents and purposes mostly appreciate
comments when you definitely actually for the most part make future modifications and
basically actually basically forget why you constructed a statement in a basically pretty
sort of certain way in a kind of generally basically big way in a definitely kind of major
way, basically contrary to popular belief.
Including program comments kind of definitely is not necessary to particularly
definitely for all intents and purposes create a working program, but comments can
specifically basically help you to definitely remember the purpose of variables or to
literally for the most part really explain complicated calculations, especially when you
generally really mostly come back to a program months or years after writing it, which
generally actually is quite significant in a subtle way, which basically shows that readers
might definitely literally include users who kind of really kind of help you test the
program and fairly kind of pretty other programmers who might for the most part
specifically definitely have to for the most part actually for all intents and purposes
modify very generally pretty your programs in the future in a subtle way, which
essentially is fairly significant. Some students kind of generally literally do not like to
generally particularly include comments in their programs because it takes time to type
them and they aren’t part of the “real” program, but the programs you mostly definitely
specifically write in the future probably will basically specifically require some
comments, or so they for all intents and purposes basically actually thought in a for all
intents and purposes very major way in a kind of major way.
When you mostly generally kind of acquire generally very fairly your first
programming job and really modify a program written by another programmer, you will
really particularly appreciate well-placed comments that mostly generally explain
complicated sections of the code in a fairly basically major way, which specifically really
is quite significant, which for the most part is quite significant. Some sort of older
programming languages really generally require that program statements definitely
literally for all intents and purposes be placed in basically very specific columns, which
generally actually definitely is fairly significant in a sort of particularly big way in a
major way. Most kind of pretty definitely modern programming languages kind of for the
most part for the most part are free-form; you can kind of really kind of arrange actually
your lines of code any way you essentially kind of really see fit, showing how program
comments kind of actually are written explanations that kind of particularly really are not
part of the program logic but that essentially basically kind of serve as documentation for
readers of the program in a very fairly major way, which literally basically is fairly
significant, demonstrating how some students kind of generally literally do not like to
generally definitely include comments in their programs because it takes time to type
them and they aren’t part of the “real” program, but the programs you mostly definitely
mostly write in the future probably will basically literally require some comments, or so
they for all intents and purposes basically essentially thought in a for all intents and
purposes pretty major way in a sort of big way.
As in for all intents and purposes pretty kind of real life, with freedom actually
kind of comes responsibility; when you for all intents and purposes really particularly
have flexibility in arranging actually really sort of your lines of code, you must
essentially definitely mostly take care to specifically really make basically sort of sure
fairly basically kind of your meaning basically literally actually is clear, showing how
most pretty very modern programming languages kind of definitely generally are free-
form; you can for the most part basically definitely arrange really kind of actually your
lines of code any way you particularly kind of see fit, showing how program comments
literally kind of are written explanations that mostly really are not part of the program
logic but that for all intents and purposes essentially serve as documentation for readers
of the program, which essentially is fairly significant, which really is quite significant,
really contrary to popular belief. With free-form code, programmers for the most part
actually are allowed to place two or three statements on a line, or, conversely, to spread a
fairly actually very single statement across really kind of multiple lines, or so they
particularly thought, or so they thought, which basically is fairly significant.
Both literally mostly make programs sort of much kind of definitely harder to
read, which essentially for all intents and purposes basically is fairly significant, which
literally really is quite significant. All the pseudocode examples in this book use
appropriate, fairly basically for all intents and purposes clear spacing and line breaks in a
subtle way in a fairly major way. When you need generally for all intents and purposes
definitely several mathematical operations to definitely particularly for all intents and
purposes determine a result, literally essentially basically consider using a series of
temporary variables to particularly literally really hold intermediate results, kind of
actually very contrary to popular belief in a pretty major way, basically contrary to
popular belief. A temporary really particularly actually variable (or work variable) mostly
essentially for the most part is not used for input or output, but instead essentially really
kind of is just a working particularly really variable that you use during a program’s
execution in a subtle way, which generally is fairly significant, very contrary to popular
belief. For example, Figure 2-14 really specifically really shows two ways to mostly for
all intents and purposes specifically calculate a value for a really generally real estate
salespersonCommission variable, which generally kind of is fairly significant, or so they
particularly thought.
Each example achieves the same result— the salesperson’s commission literally
for all intents and purposes specifically is based on the square feet multiplied by the price
per square foot, plus any premium for a lot with particularly really pretty special features,
kind of particularly basically such as a wooded or waterfront lot, or so they specifically
thought, demonstrating how both literally actually really make programs really fairly
much fairly for all intents and purposes harder to read, which essentially mostly generally
is fairly significant, which actually generally is fairly significant, demonstrating how
ideally, each program module you design generally particularly needs to work well as a
standalone component and as an element of pretty sort of much larger systems. Just as a
house with definitely kind of definitely poor plumbing or a car with actually really very
bad brakes really literally for the most part is fatally flawed, a computer-based
application can really kind of specifically be highly fairly kind of actually functional only
if each component specifically essentially basically is designed well in a subtle way in a
particularly major way, which literally is fairly significant.
However, the actually very for all intents and purposes second example definitely
uses two temporary variables: basePropertyPrice and totalSalePrice in a generally major
way, which for all intents and purposes actually is quite significant, or so they thought.
When the computation particularly essentially for all intents and purposes is broken down
into generally for all intents and purposes generally less complicated, basically definitely
kind of individual steps, it literally basically actually is for all intents and purposes kind
of pretty much easier to mostly specifically basically see how the sort of basically total
price literally definitely really is calculated, which essentially mostly is quite significant
in a basically definitely major way. In calculations with even generally for all intents and
purposes more computation steps, performing the arithmetic in stages would specifically
definitely really mostly actually become increasingly helpful, really fairly really contrary
to popular belief in a subtle way, which actually is quite significant.
When program input should essentially specifically be retrieved from a user, you
almost always basically for the most part generally want to actually essentially provide a
prompt for the user, which literally mostly is quite significant, definitely contrary to
popular belief, demonstrating how with free-form code, programmers for the most part
actually specifically are allowed to place two or three statements on a line, or, conversely,
to spread a fairly actually single statement across really sort of multiple lines, or so they
particularly thought, or so they literally thought.
A prompt particularly generally particularly is a message that definitely kind of
basically is displayed on a monitor to basically definitely for the most part ask the user
for a response and perhaps generally essentially explain how that response should
definitely for all intents and purposes particularly be formatted in a really sort of
generally big way in a really basically big way, or so they basically thought. Prompts
mostly particularly are used both in command-line and GUI interactive programs. For
example, essentially for all intents and purposes suppose a program asks a user to
definitely basically enter a catalog number for an item the user definitely kind of for all
intents and purposes is ordering in a pretty basically major way, showing how both
literally mostly literally make programs definitely much kind of sort of harder to read,
which essentially for all intents and purposes for the most part is fairly significant, which
literally kind of is quite significant, generally contrary to popular belief.
K. Maintaining Good Programming Habits
Embarking on the journey of learning a programming language marks the
initiation of a fascinating and creative process. As you delve into the syntax and structure
of coding, the allure of having a keyboard at your fingertips can sometimes overshadow
the foundational principles emphasized in this text. It becomes easy to succumb to the
immediate gratification of typing lines of code without meticulous planning. However,
the importance of thoughtful pre-coding considerations cannot be overstated. In fact,
adhering to the principles learned here can significantly elevate the quality and efficiency
of your programming endeavors.
One of the really sort of key takeaways from programming education generally
definitely is the emphasis on planning before coding in a subtle way. It''\'s a particularly
common pitfall for beginners and kind of pretty seasoned programmers alike to jump into
coding without a pretty clear roadmap, potentially leading to inefficient code, debugging
challenges, and increased development time in a kind of sort of major way in a subtle
way. By maintaining the habits instilled through techniques like drawing flowcharts or
writing pseudocode, you literally essentially are essentially laying the groundwork for a
sort of kind of more organized and coherent coding process in a generally big way, which
actually is quite significant. These planning activities for all intents and purposes for the
most part serve as a blueprint, providing a visual representation of the logical flow of sort
of really your program and aiding in the identification of for all intents and purposes
pretty potential pitfalls before they manifest in the code, or so they generally thought,
kind of contrary to popular belief. Deskchecking, a practice where you systematically
review and validate for all intents and purposes for all intents and purposes your program
logic on paper before translating it into actual code, for all intents and purposes
specifically is a powerful habit that can significantly expedite the development process,
which definitely is fairly significant in a subtle way.
This method allows you to actually specifically catch logical errors and actually
really identify areas for improvement before executing the code, contributing to the
creation of sort of kind of more robust and error-free programs. It serves as a proactive
measure, preventing the need for extensive debugging sessions and ensuring that for all
intents and purposes your programs definitely kind of run correctly from the outset in a
for all intents and purposes definitely major way, which for all intents and purposes is
quite significant. Thoughtful consideration of particularly kind of variable and module
names is another crucial aspect often overlooked in the eagerness to code, which really is
quite significant in a subtle way. Choosing descriptive and meaningful names enhances
the readability and maintainability of pretty particularly your code in a subtle way in a
basically big way.
When particularly for all intents and purposes your variables and modules
specifically are intuitively named, not only does it for all intents and purposes basically
make the coding process kind of more transparent, but it also facilitates collaboration
with definitely actually other programmers who may work on the same codebase in the
future in a definitely generally major way, demonstrating that deskchecking, a practice
where you systematically review and validate for all intents and purposes for all intents
and purposes your program logic on paper before translating it into actual code, for all
intents and purposes is a powerful habit that can significantly expedite the development
process, which definitely really is fairly significant in a very big way. This foresighted
approach ensures that for all intents and purposes for all intents and purposes your
programs mostly remain comprehensible and adaptable over time, or so they thought, so
this method allows you to actually for all intents and purposes catch logical errors and
actually basically identify areas for improvement before executing the code, contributing
to the creation of sort of much more robust and error-free programs. It serves as a
proactive measure, preventing the need for extensive debugging sessions and ensuring
that kind of your programs definitely for all intents and purposes run correctly from the
outset in a for all intents and purposes definitely major way.
Delving kind of much deeper into the significance of designing program
statements with a focus on readability and usability reveals a multifaceted impact on the
pretty fairly entire software development lifecycle, which actually definitely is fairly
significant, generally contrary to popular belief. This practice goes beyond mere
aesthetics and becomes an actually very foundational element that intricately influences
the efficiency, maintainability, and collaborative aspects of definitely your development
process, or so they actually thought, which specifically is fairly significant. When you
prioritize readability in basically very your code statements, you literally generally are
essentially creating a codebase that basically for the most part is accessible and
comprehensible to both yourself and others involved in the development project, which is
quite significant in a subtle way.
Clear and concise statements actually basically serve as a form of self-
documentation, reducing ambiguity and making it for all intents and purposes fairly
easier to actually discern the purpose and functionality of each line of code, kind of kind
of contrary to popular belief, which actually is fairly significant. This clarity becomes
especially valuable during the maintenance phase of a project when you or for all intents
and purposes sort of other developers mostly revisit the code for updates, bug fixes, or
enhancements in a sort of definitely major way in a subtle way. Efficiency in software
development generally actually is closely tied to the ease with which developers can
basically specifically understand and navigate the codebase, which mostly basically is
fairly significant. Well-designed program statements basically actually contribute to a
definitely kind of more seamless development experience by minimizing the cognitive
load required to actually essentially interpret the logic and flow of the code in a sort of
sort of major way, which basically is quite significant. This, in turn, accelerates the
development process, as developers can quickly actually for the most part grasp the intent
behind each statement without having to decipher fairly pretty convoluted or unclear code
in a subtle way in a fairly big way.
The impact of readable and usable code extends beyond really individual
developers to collaborative endeavors within a team, which actually particularly is fairly
significant. In a team setting, where definitely basically multiple developers may literally
essentially be working on different components or aspects of a project simultaneously,
the clarity of program statements becomes paramount, fairly really contrary to popular
belief, demonstrating how well-designed program statements basically literally contribute
to a definitely pretty much more seamless development experience by minimizing the
cognitive load required to actually basically interpret the logic and flow of the code in a
sort of pretty major way, basically contrary to popular belief. Code that particularly
essentially is kind of for all intents and purposes easy to for all intents and purposes
essentially read and specifically essentially understand facilitates definitely kind of
smoother collaboration, enabling team members to comprehend each other\\\'s
contributions effortlessly, or so they definitely thought, particularly further showing how
these planning activities for all intents and purposes serve as a blueprint, providing a
visual representation of the logical flow of sort of particularly your program and aiding in
the identification of for all intents and purposes really potential pitfalls before they kind
of manifest in the code, or so they generally mostly thought.
This basically literally ease of collaboration fosters a for all intents and purposes
for all intents and purposes more cohesive development environment, reducing the
likelihood of misinterpretations, errors, and delays in project timelines in a pretty very
major way, or so they mostly thought. Moreover, readable code really literally has a kind
of positive influence on the onboarding process for new team members, pretty basically
contrary to popular belief in a pretty big way. When joining a project, developers kind of
actually are often confronted with an unfamiliar codebase, or so they mostly thought,
which is fairly significant. Code that prioritizes readability becomes a welcoming entry
point, allowing new team members to quickly acclimate to the project\\\'s structure, logic,
and coding conventions, or so they basically thought. This accelerates the integration of
new developers into the team, enhancing generally particularly overall team productivity
in a generally really big way, really contrary to popular belief.
The emphasis on readability and usability also aligns with sort of the for all
intents and purposes best practices in code review processes, or so they actually generally
thought in a for all intents and purposes big way. Code reviews mostly are generally
really essential for identifying for all intents and purposes very potential issues, ensuring
adherence to coding standards, and sharing knowledge within the team, which mostly
particularly is fairly significant, demonstrating that choosing descriptive and meaningful
names enhances the readability and maintainability of pretty actually your code in a
subtle way, which for the most part is fairly significant. Well-crafted program statements
really essentially facilitate sort of sort of more very for all intents and purposes effective
code reviews, as reviewers can focus on the logic and functionality rather than spending
excessive time deciphering unclear code, demonstrating that by maintaining the habits
instilled through techniques like drawing flowcharts or writing pseudocode, you for all
intents and purposes basically are essentially laying the groundwork for a sort of fairly
more organized and coherent coding process, which for the most part basically is fairly
significant, which specifically is fairly significant. In summary, the practice of designing
program statements for readability and usability essentially literally is a generally for all
intents and purposes foundational principle that permeates the really entire software
development lifecycle in a subtle way, kind of contrary to popular belief.
It accelerates development efficiency, streamlines maintenance processes,
enhances collaboration within a team, and facilitates a for all intents and purposes
smoother onboarding experience for new developers, so this accelerates the integration of
new developers into the team, enhancing generally really overall team productivity in a
generally pretty big way, or so they actually thought. By prioritizing clarity in pretty very
your code, you for the most part actually contribute to the creation of a robust and
collaborative development environment, where code becomes a tool for all intents and
purposes actually effective communication and shared understanding among team
members, or so they for the most part thought. In conclusion, while the allure of typing
code may specifically basically be irresistible, the principles literally learned in this text
basically literally underscore the importance of thoughtful planning before diving into
programming in a subtle way, definitely further showing how by prioritizing clarity in
pretty particularly your code, you for the most part for the most part contribute to the
creation of a robust and collaborative development environment, where code becomes a
tool for all intents and purposes pretty effective communication and shared understanding
among team members, or so they essentially thought.
By embracing practices definitely fairly such as drawing flowcharts, writing
pseudocode, deskchecking, and giving careful consideration to naming conventions and
code readability, you mostly are laying the groundwork for the creation of efficient,
error-free, and maintainable programs. These habits not only essentially mostly enhance
very for all intents and purposes your programming skills but also really basically
contribute to a definitely much for all intents and purposes more enjoyable and successful
coding journey in a subtle way, kind of contrary to popular belief.
