Design‎ > ‎

Coding Style

Many groups, companies and organizations have a style guide, in addition to the language
specifications.  These then require extra tools to check that the code confirms to this
style.  Or a manual verification.

When someone switches from one group to another he has to learn using a
different style.  Or there is no specific style and code written by one person looks
quite different from what someone else writes.

It is very important that code is easy to read back.  For example, consider these two
C statements that do the same:

         for(int i=0;i<max_i;++i){

         for (int i = 0; i < iMax; ++i) {
            if (count > i)


Clearly the second version is much quicker to understand.  White space is used
to separate items and consistent naming is used.

So let's enforce a reasonable style in Zimbu.

Some of the rules are:
  • a comment must always be preceded by a line break or white space.
  • most punctuation, such as a comma, must be followed by a line break or white space
  • only in some places can a semicolon be used to replace a line break
  • always use white space between operators, even when not needed for tokenization.
  • do not allow white space after an open paren/brace or before a closing paren/brace
A few examples:

 wrong    right why
 func (x)
 the argument belongs together with the function
 name, it is not a separate item
 [ item, item ]
 [item, item]
 keep it compact
 [item,item] [item, item]
 space after comma breaks the line into items
 if f#comment
 if f #comment
 a comment is a separate item
 x=y1+p3*3 x = y1 + p3 * 3
 put spaces between items and operators