How to write easily understood Turbo Integrator code

As many of TM1 consultants know, reading TI code always has the possibility of being a tricky task – especially if it is someone else’s code. This is mostly due to TM1 Perspectives Turbo Integrator lacking Syntax Highlighting (See our Notepad++ highlighter) but in part it is due to poor variable naming, indenting, casing or things simply not developed consistently throughout the model.

My recommendations for writing turbo integrator code, which can easily be read and more importantly understood:

Variable Naming:

Variable names should start with a type indication letter then followed by logical name starting with a capital letter i.e. nTotalSales or cCubeName.

The following prefixes give you enough flexibility and are easy to remember:

  • c for constants
  • n for numeric variables
  • s for string variables
  • p for parameters
  • b for bool/logic values

Constants are specified in Prolog/Epilog sections (common usage is cube or dimension name) and do not change during TI execution. It is extremely useful to set constants for all static things that TI refers to. This eliminates repeated manual entry and minimizes time to modify a TI.

Boolean or logic values are not necessary but can make one`s life easier.

Function Calls:

I recommend reserved TM1 words like ELISANC or DIMIX to be spelled in capitals can help to avoid possible confusion with variables or constants.

Indentation:

Last but not least, indentation, which not many people know is actually a built-in function. The hotkey is Ctrl+I and it works like TAB in other text editors. The only thing that could upset TI editor is that an indent is treated as a special character and it does not act like space, so that  ‘           TAB     ’ and ‘        SPACES        ‘ are treated differently: spaces are ignored while indents are not.

If you like this post, please spread the love…

4 comments on “How to write easily understood Turbo Integrator code

  1. James Webber says:

    Thanks Ivan,

    I see IBM’s recommendation(in the official TM1 guide page 217) is similar
    ps = Parameter String
    pn = Parameter Number
    pi = Parameter Integer
    pb = Parameter Boolean
    vs -> vb for Variables
    gs-> gb Global
    s->b for other variables

    They also suggest common attributes like “prev” and “next”
    Wont it be great if we all followed a similar convention?

  2. Maximilian Parsons says:

    Thanks for this. Pretty much following all of these already.

    Some other conventions I follow, mostly picked up from various consultants I’ve worked with:

    ‘i’ prefix for integer variables
    ‘cub’,’dim’,’elm’,’sub’ and ‘vue’ prefixes for associated objects

    I also capitalize datasource fields, to distinguish them from process-generated variables.

    When constructing views, I’ll list the cube dimensions, specifying which element(s) are being selected. Saves having to parse the detail when you come back to a process months later.

    Also good to have a consistent, logical naming convention for your processes e.g. Data_Load_XXX, Data_Copy_XXX, Meta_Create_XXX etc. I’ll sometimes prefix these with a two-letter prefix to group processes by application.

  3. Great topic Ivan!
    Ben Hill: Thanks for posting a link to this discussion on the LinkedIn IBM Cognos & TM1 Consultants Group!

    Here is what I would add:

    Spacing improves readability.

    Example without spaces:
    nCellValue=CellGetN(cCube,sDim1,pDim2,ATTRS(sDimRef3,sDimElem3,’Code’),SUBST(sAcct,1,SCAN(‘-‘,sAcct)-1,ELCOMP(sDim5,sQtr,1));

    Example with spaces:
    nCellValue = CellGetN ( cCube, sDim1, pDim2, ATTRS ( sDimRef3, sDimElem3, ‘Code’ ) , SUBST ( sAcct, 1, SCAN ( ‘-‘, sAcct ) – 1, ELCOMP ( sDim5, sQtr, 1 ) ) ;

    For indenting, I always use four spaces.
    I also establish code blocks with blank lines inbetween and lots of comments explaining what the code is doing, not mechanically, but from a business rule and higher level perspective.

    Placing comment characters at the beginning and end of the line also helps it to stand out.

    # Comment line. #

    For emphasis, use more comment characters:

    #########################
    ### !!! ATTENTION !!! ###
    #########################

    These are simple examples with which more can be done such as object naming conventions, standardized code snipets, etc.

    Best wishes and happy coding!

  4. Ivan Kulman says:

    Thank you very much for your comments! 🙂

    James, thanks for this.

    Maximilian, good point. Using “}Sys.” as a prefix hides the object. Might be useful for TI generated subsets or views.

    Christopher, spaces also allow you to navigate through the code using ctrl + arrow keys.

    Every consultant is still going to have their own style but getting some common code features should make consultants ` life easier.

This site uses Akismet to reduce spam. Learn how your comment data is processed.