Coding

1. Coding Chapter 12

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.)

8. 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.

9. 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.

10. 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!)

11. 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!

12. 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.

13. 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!

14. 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.

15. 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.

16. 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.

17. 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.

18. 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!

19. 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!