Home Documentation MUF Docs GlowMUF Downloads Bug Tracking Support Requests Feature Requests

GlowMUF Nitpick List

Every program should following the filename/database item name convention of programtype-programname, e.g., cmd-foobarbaz. Current identified types are: cmd, con, game, lib, lock. Further types may need to be identified.
Every installer script should a mechanism for notifiying the installer both of commencement of installation and completion of the installation. Possibly 'whisper' will be the preferred method.
Every program should have a _version or _lib-version prop, or both. The prop should contain at minimum the FM$Revision$ tag, in additional to any pre-existing version information.
Every program should be registered in the appropiate registry directory, currently the directory corresponds to the types above.
Every program should have the _docs property set to issue the correct command for viewing the help/documentation for the program. If the program has its own help, it should simply contain that command. Otherwise, it should contain something like: @list $lib/strings=1-50. Setting this property appropiately allows the @view command operate correctly.
The program should have as complete a set of documentation in the program comments as possible. Each line of this documentation should begin with an open parentheses '(' and end with a closing parentheses ')'. This allows the MUF editor's 'view' command to operate correctly. Further all comments in heading and help areas should be full-block, the parens positioned at column 1 and column 79, respectively. An except is made for $ entries, due to the way CVS/RCS operates on such entries.
The first lines of the documentation should be as follows. Like the documentation these lines should begin and end with parentheses.
1. type-programname: $Date$ $Revision$
2. Purpose: Statement of purpose
3. Author: Authorname or Unknown
4. Contributors: List of people contributing fixes/features
5. Dependencies: List of libs that this program relies on.
6. -----------------------------------------------...
7. Any pre-existing docs should go here
8. (
9. $log$
10. )
Library words/functions should be named in a fashion that makes it clear which library is being called. Likewise, all the library calls should be updated to use the clearer naming convention. The existing names should be kept for the words for backwards compatibility. The format for this naming convention is XXXXwordname, e.g., STRparse, SRNGinsertrng, LOOKdbdesc, etc. The documentation, of course, should be updated correspondingly.
The /_/de property (description) should be set as appropiate, either pointing the user to the documentation/help, or executing the appropiate command for getting that very same help.
All the @set commands should use $type/programname instead of the $tmp/prog1 paradigm that is the result of @archiving ages ago. And then remove the redundant #me @reg command in the script.
None of these programs should use macros. Use of macros drastically reduces the portability of programs.
Many of the programs maintain functionality by replacing macro calls with calls to lib-glow-standard. Ideally, these should be replaced by local code or calls to more appropiate libraries.