1 / 13

Software Engineering

Table-driven methods General control issues. Software Engineering. Table-driven methods. A table-driven method is a schema to look up information in a table instead of using (possibly complicated) logical statements ( if and case, for example). Table-driven methods. General considerations:

burrisa
Download Presentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Table-driven methods General control issues Software Engineering

  2. Table-driven methods A table-driven method is a schema to look up information in a table instead of using (possibly complicated) logical statements (if and case, for example).

  3. Table-driven methods General considerations: How to index the dimensions of a table, to avoid making it unnecessarily sparse and to make it easy to access. What to store inside the table – data or actions. How to declare a table in your language, so that it can accommodate its contents.

  4. Table-driven methods Table organisation: Direct access tables: dimensions represent meaningful values of variables. if (month = 1) { days = daysPerMonth(month - 1); days = 31; } else { daysPerMonth = if (month = 2) { days = 28; } else (...) 31 28 31 30 ...

  5. Table-driven methods Table organisation: Indexed access tables: values point to indices that point to the table. value value index index

  6. General control issues Boolean expressions: When appropriate, compare boolean values to true and false implicitly. Instead of:while (done == false) ...while ((a>b) == true) ... Give preference to:while (! done) ...while ( a > b ) ...

  7. General control issues Boolean expressions: Simplify complicated expressions: Break complicated tests into partial tests with new boolean variables. Move complicated expressions into boolean functions. Use decision tables to replace complicated conditions.

  8. General control issues Boolean expressions: Form boolean expressions positively: “I ain't not no undummy.” Homer Simpson In if statements, convert negatives to positives and flip-flop the code in the if and else clauses. Use DeMorgan's laws to simplify boolean tests, e.g. prefer (A || B) to (!(!A && !B)).

  9. General control issues Boolean expressions: Use parentheses to clarify boolean expressions. Do not rely on the language's evaluation order. Use redundant parentheses if appropriate to make the expression more readable. Write numeric expressions in number-line order, e.g. MIN <= i && i <= MAX, i < MIN || MAX < i.

  10. General control issues Compound statements (blocks): A compound statement is a collection of statements that are treated as a single statement for purposes of controlling the flow of a program. They are usually tagged by some language-specific symbol, e.g. { ... }.

  11. General control issues Compound statements (blocks): Write pairs of braces together. Fill in the middle after you write both the opening and closing parts of a block. Use braces to clarify conditionals. Use blocks to clarify your intentions regardless of whether the conde inside the block is 1 line or 20 lines long.

  12. General control issues Simplifying deep nesting: Deep nesting = more than three levels of nesting. Deep nesting should be avoided by restructuring the code. Simplify a nested if by re-testing part of the condition. Convert a nested if to a set of if-then-else's. Convert a nested if to a case statement.

  13. General control issues Simplifying deep nesting: Factor deeply nested code into its own routine. Create specific routines for more internal tests, and leave general structure in root routine. Entirely redesign deeply nested code.

More Related