coding

19
Coding Chapter 12

Upload: cassidy-drake

Post on 30-Dec-2015

26 views

Category:

Documents


0 download

DESCRIPTION

Coding. Chapter 12. Programming Languages. Programming languages come in many flavors (procedural vs. functional, etc.). There are some qualities that can be used to separate the programming languages into groups, such as strong vs. weak typing data encapsulation and so on. Strong Typing. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Coding

Coding

Chapter 12

Page 2: Coding

Programming Languages Programming languages come in many

flavors (procedural vs. functional, etc.). There are some qualities that can be used to

separate the programming languages into groups, such as strong vs. weak typing data encapsulation and so on.

Page 3: Coding

Strong Typing Strong typing means that the language

restricts the use of values or variables to “proper” contexts.

An example of strong typing is when a routine’s declared return type or parameter list does not agree with the way it is used in the code.

Page 4: Coding

User-defined Types Many modern languages provide for user-

defined types, such as aggregate structures (such as “C” struct definitions)

Also, abstraction of data types are permitted in many instance.

This can allow for the protection of implementation details via encapsulation.

Page 5: Coding

Encapsulation for Data Abstractions Data abstractions are protected by

encapsulation: restricting the view of internals to only the items that are internal (encapsulated) in the data type itself.

Object-oriented programming languages encapsulate the “methods” for manipulating the data, as well as the data itself.

Page 6: Coding

Run-time Checking Detection of defects that exhibit themselves at “run-

time” (execution) require checking at run time. Typically these are data limit errors like bounds violation on arrays, or invalid pointers.

Run-time checking generated by the compiler typically comes at the expense of execution speed, unless there is hardware support.

Page 7: Coding

Program Redundancy Checking Validation of data structure at strategic points is a

form of redundancy checking. Checksums on a struct is one way to accomplish this.

In addition, computing values using two different means (multi-version programming), can also find errors.

In addition, deliberately looking for “impossible conditions” may just turn up the fact that the impossible did happen (assertive programming is a way to accomplish this.)

Page 8: Coding

Assertions The use of assertions allows the programmer to

“assert” that certain inviolate conditions exist. In other words, the programmer may code a statement that says: “At this point in the program, it is a FACT that the value of variable a is greater than 0.”

If this fact is not true, a message is printed, and the program halts.

Page 9: Coding

And When a Problem is Caught-What Then? Science favors the prepared mind: When the

run-time error is caught, unless we are using a debugger, we must “dump” information that we think might be useful in isolating the problem. We must try to guess what these might be in advance!

Now we must try to find a bug that we were certain couldn’t exist! This is not easy.

Page 10: Coding

Macro Capability Macros allow the programmer to ‘hide’ or ‘abstract’

operations using a macro. Macros can ‘masquerade’ (look like) function calls. Macros can, however have irreversible side-effects

that are concealed (for example, if the statement ‘i++;’ is in the macro, it changes the value of i, and the programmer using the macro may not be aware of this!)

Page 11: Coding

Programming-language Libraries Many programming languages provide a set

of standard functions pre-written for the programmer to use. Typical of these functions are arithmetic functions (power, factorial, etc.) and string functions.

Programming-language libraries have the benefit of having been pre-coded and tested: two real time-savers!

Page 12: Coding

Error-prone Programming Language Constructions Sometimes there are obvious ways to

introduce problems into programming environments (such as the macro side-effect mentioned previously).

These can be avoided with experience, and by introducing programming standards which discourage these sorts of problems.

Page 13: Coding

Choosing a Programming Language Typically, we would chose a programming language

based on it’s virtues for the task at hand. Sometimes the best language is one we’re already

familiar with because experience is one of the best ways to reduce pitfalls and cut down on the ‘learning curve.’

Studies indicate that the team and the environment are far more important to productivity and quality than the programming language!

Page 14: Coding

Languages for Rapid Prototyping Many of the ‘classic’ rapid prototyping languages

(such as Smalltalk) are good for prototyping GUIs, but there are other things to prototype.

As we have seen, Prolog can be used as a prototype specification language.

Shell programming languages often help us ‘piece together’ existing programs to prototype the execution of a larger program.

Page 15: Coding

Support Tools for Programming Programming tool support is an essential part

of a well-balance development environment. The early Unix environment used toolsets

geared toward basic programmer's tasks: checking program structure against rules, finding character strings in a file set, scripting capabilities, etc.

Page 16: Coding

Language Analyzers - lint ‘lint’ was an early tool used to check

argument types and return types for function calls against a database of types known for that function. This would trap type mismatches in function calls and their return values.

Page 17: Coding

The make Utility The ‘make’ utility allows programmers to build

systems that may be large and complex by recompiling and linking only the files that have changed during a development session.

The ‘make’ facility provides programmers with the capability to define either general or file-specific rules about system construction that are applied when a file changes.

‘make’ ensures that systems are consistently built, reducing the risk that problems will be introduced.

Page 18: Coding

Version-control Tools Construction of complex and large systems are

typically error-prone. Sometimes, it is necessary to ‘back out’ changes of a file to a ‘previous version.

Version control tools permit exactly that: provided they are used properly.

In addition, version-control tools can be applied to documents (such as specifications), not just programs!

Page 19: Coding

Adding to the Test Plan while Coding During the coding phase, programmers and

testers will encounter code segments that they feel should be heavily tested. These cases can be added to the test plan as they are encountered.

The exhaustive or specialized testing of critical sections can be identified during this time!