We've discussed basic troubleshooting and logic. However, if we are going beyond attempting to emulate simple mathematics, we need a dictionary to provide meaning to the conversation between the user and the computer. In many languages these are defined in multiple places including the most useful and dangerous of them all -- libraries not designed and tested by the standards committees.
Suppose you have a library called "Corp_ScreenManagement_v1" which names the accessible functions in the format of csm_XXX where XXX is a numeric code instead of a descriptive tag.
If the library is properly documented you will know the three key points of any particular function: return type, parameter variables, and most importantly its designated use and expected effects or results. As demonstrated before, the documentation may look like this directly in the source:
//csm_XXX: Prints texts on the screen
// Parameters: INTEGER xCoord, INTEGER yCoord, ARRAY characters
// Returns: BOOLEAN TRUE on Success
BOOLEAN csm_XXX( INTEGER xCoord, INTEGER yCoord, ARRAY characters )
...
The documentation file should, depending on the language provide much the same information, perhaps in an even clearer format than what the original programmer provided. This allows us to create a series test cases for it so that we can prevent error states when using this function. If the function doesn't conform to the documentation, we can update the documentation or contact the libraries support staff for corrected files.
No comments:
Post a Comment