It is best to keep each individual list as short as possible. Lists can be created or separated as collections of tasks/items that “fit well together”, which can mean:
A list should be named according to what it represents. It is better to have a longer name that explains what the list does or what it means, rather than a short name that isn't very clear. A result of breaking things up may be having lists that are mostly composed of link lines, which is readable when the lists linked-to have descriptive names. If desired, a list name can be given a file extension (e.g. file.txt). However, an extension is not necessary and might be confusing. Linking to such a list would require that the file extension be included in the link line.
Any time you realize that a specific set of items will be used in more than one place, cut that section and paste it into a new list. Once created, it can then be linked-to from many different places. The advantage is that when some task or detail changes, it only needs to be changed in one list. This avoids the problem of changes to be made in scattered locations, but one of them gets missed.
Re-organizing lists and folders by moving or renaming them is a natural result of this process. When a list is renamed or moved, all of the lists that link to it are automatically updated with the new name/location.
Create a folder when it becomes sensible or necessary to group some lists together. Folders can be created within other folders. As with lists, use names that are descriptive and helpful; a name that applies to all of the lists within. Another benefit of adding folders is that the lists they contain can have shorter names.
It is natural for lists to be written in the intended order of execution. However, when conditional items are introduced, a chronological order becomes increasingly difficult when writing a flat list the conventional way. The difficulty arises because there are really only two ways of dealing with conditionals:
clir makes it possible to have conditional branches in as many places in a list as necessary, while hiding all the details; they are seamlessly added into the final checklist. With other markup tag features like list links and assignments, the natural flow of a routine can be perfectly maintained.
Using descriptive names for folders and lists is important for readability. This is also true for variable names. In a prompt or assignment, use a name that best explains its purpose. It is possible to write them in the form of camelCaseNames
or underscore_separated_names
, for example. This section covers variable naming rules.
Quantities can be used in lists to represent the number of pieces to order, the number of attendees in a meeting, etc. Use a number prompt to get a quantity from the user. If necessary, that quantity can be changed in an assignment, for example to scale it by a certain amount, or add/reduce the count, etc. The quantity can ultimately be used into a list line by using a text substitution.
Use a text prompt to get a name, label, or description from the user for certain items in a list. Examples include category or header names, customer names, labels for sub-routines, etc. The names can then be used by text reference to create seamless custom text in the output checklist.