Humanities Technology and Research Support Center
Back     CHum LiveCode Gateway

Best Practices
in LiveCode Development

What are "Best Practices"? In general terms it refers to an approach to quality and efficiency based on rules developed through experience. In essence it means developing good habits that will make your work better and more efficient in the long run. In the context of software development it refers to using techniques in a disciplined way that will make your development process more efficient, and ensure that your project is easier to modify in the future, both for yourself and others. (It also makes it easier for your teacher to evaluate!)

  1. Name all objects—stacks, cards, fields, buttons, groups, etc. as you create them.
  2. Use meaningful names that will tell you at a glance what the object is for. Naming a card "c2" won't be very helpful if you end up with 20 cards in your stack. A name like "mainMenu" reminds you at a glance what is on that card.
  3. Use names and titles or labels for stacks and buttons. For stacks, a title makes the stack look more finished and professional (no * in the title bar.) For buttons, a label allows you to keep the button name succinct but still label it in a clear way.
    It also avoids problems later; if you decide the button's label needs to change, your scripting, which may refer to buttons by name, doesn't get messed up.
  4. Set properties as far up the hierarchy as possible. This ensures that that the objects in a stack maintain a consistent look throughout. It also makes it easy to change the look or behavior of objects all at once instead of individually. For example, if you know that you want all of your fields and buttons to use the Arial font, set it for the stack. You can still change properties for child objects if you need to, but you won't have to set each object individually if you later decide that your objects really should use Times New Roman font.
  5. Use comments to document your handlers. This applies to all but very simple (one or two line) handlers. At a minimum you should include a comment at the beginning of the handler describing briefly what it does; in long, complex handlers you should include comments that describe what each section does.
  6. Place a handler as far up the message hierarchy as it needs to be, but no farther. In other words, if several controls do virtually the same thing, a handler placed in an enclosing group or a card might be the most efficient placement. On the other hand, don't just throw all of your handlers in a stack script, since not all handlers are needed everywhere in the stack.
  7. Use the "complete" form of the if-then-else control structure to avoid ambiguity. Each if structure should have the form:
        if condition then
        else  -- (if you need an else clause)
        end if
  8. Consider cross-platform issues. Because LiveCode is a cross-platform development environment, you should always test your stacks on all platforms you plan to deliver them on. For this course, you should at a minimum open your stacks on both Windows and Macintosh OS X computers and check things like colors, text size, object styles and alignments.
  9. Use meaningful names for object names, variables and custom handlers. This will make your code much easier to read and reduce the need to write extensive comments to explain your handlers. For example, this
        put the number of lines in field "questions" into numberOfQuestions
        if numberOfQuestions < 10 then
          put "You only have" && numberOfQuestions && "left to answer!" into field "progress"
        end if
    is much easier to read than this
        put the number of lines in field "q1" into nqs
        if nqs < 10 then
          put "You only have" && nqs && "left to answer!" into field "prg"
        end if
    The small amount of extra time it takes to type longer but meaningful names will be more than offset by the time you will save later in debugging and commenting your handlers.

Back     CHum LiveCode Gateway
Maintained by Devin Asay.
Copyright © 2005 Brigham Young University