1.1.8 Importance of user documentation
IB Subtopics
User documentation can be provided in a variety of forms, both online and offline. It should include instructions that are mandatory for the system to operate and should contain frequently asked questions, which are always necessary for new users. (you don’t have to include the following for your IA’s client)
Possible types of documentation for users include:
Possible types of documentation for developers include:
We’ve use a style guide for Java in this course, but you might be using a different language for your project. You and your team must decide on a style and make sure to stick to it. The style, above all, needs to be consistent.
However, across any language you must remember the following:
• Structure and layout of your code is logical and easy to follow
• Comments in-line code (ideally following the conventions for your programming language)
• Names are meaningful and follow a consistent scheme (variables, methods, classes)
• Use of Input validation techniques
• Data is well structured (eg: use arrays/objects to avoid names like player1, player2, players)
• The use of global variables is minimized or avoided altogether. Where used they have been well justified.
• Use of error checking to “fail gracefully” (file exceptions, network exceptions, user input exceptions, etc)
• Make sure to let the user know when something went wrong
• Use of presentation and logic code separation where practical (model-view-controller or similar)
• Use of an elegant abstraction of classes, properties and/or methods.
• Use of algorithmic thinking that is elegant &/or efficient in their operations.
• Use encapsulation to avoid dependence on or creation of side-effects
• Functions are sufficiently modular so each achieves one task