TM1 Naming Conventions

[John Hammond]

Hello folks

Just thought I would raise a topic which possibly everyone has an opinion - naming conventions.

Here's what I think would be my 10 recommendations, but I am sure there are some better ideas out there and I am just interested in how others do things.

1. Chose either Camel or underscore convention and decide if blanks allowed outside of subset names and stick with it
2. No need for inclusion of type eg dim/cub in name since this is obvious from the Explorer display.
3. No special characters to be used eg Budgets&Forecasts should be outlawed since it affects other tools.
4. Try to have some consistency in creating dummy codes to store actuals at consolidation points eg dummy could be consolidation name + fullstop.
5. Dynamic Subsets and Views to be named after the process which creates it.
6. Create a single Measures dimension used as a data dictionary but never in a cube as each cube has its own measures dimension named <cube_name>Measures which is a subset of the Measures dimension.
7. Procedures should be named starting with the system to which they apply. eg MMR<description> so all procs of the same system are alphabetically sorted together though they also can be referenced through applications.
8. A chore always consists of a single process which it is given the same name from. Do not use chores to group run processes as there is no error checking.
9. TI variables should be named after the dimension being imported. v<variablename> could be used for user created variables certainly p<parametername> should be used for parameters. I would not be inclined to name variables with their type eg numeric/string/date.
10. Action button TIs should be named after the template from which they are called eg MMR_AB_<template_name>

Any comments?

Regards

John

[Alan Kirk]

Hello folks

Just thought I would raise a topic which possibly everyone has an opinion - naming conventions.

Here's what I think would be my 10 recommendations, but I am sure there are some better ideas out there and I am just interested in how others do things.

1. Chose either Camel or underscore convention and decide if blanks allowed outside of subset names and stick with it

Camel case is M$'s "flavour of the month" which it recommends for .Net development. I don't really see the point or advantage in it but if others like it, hey, go for it. I tend to stick to mixed case for object names and still use a modified version of Hungarian for variable names (except for those from a data source).

2. No need for inclusion of type eg dim/cub in name since this is obvious from the Explorer display.
3. No special characters to be used eg Budgets&Forecasts should be outlawed since it affects other tools.

Oh yeah. Serious level oh yeah. Even spaces are outlawed in object names in my environment. Can't do anything about what people name private subsets and views, but you won't find them in cubes, dims or base element names (as opposed to aliases) where I work.

4. Try to have some consistency in creating dummy codes to store actuals at consolidation points eg dummy could be consolidation name + fullstop.
5. Dynamic Subsets and Views to be named after the process which creates it.

I think you mean "transient" rather than "dynamic" (i.e. ones which live for the life of the process/chore only as opposed to ones based on MDX), and if so, yes. We also add a number representing the number of times that a chore has been executed (derived from our control cube) to any subset names which are created and destroyed during a chore's lifetime. That means that if one subset "locks" (can't be deleted/recreated), it won't interfere with subsequent executions of the chore. In such a case those locked subsets may be left behind and need to be manually cleaned up, but that's not a big issue.

6. Create a single Measures dimension used as a data dictionary but never in a cube as each cube has its own measures dimension named <cube_name>Measures which is a subset of the Measures dimension.
7. Procedures should be named starting with the system to which they apply. eg MMR<description> so all procs of the same system are alphabetically sorted together though they also can be referenced through applications.

The processes which relate to a single chore have a single 3 to 5 character tag (as above), but we follow that with a sequence number (_010, _020 etc) so that they appear in execution order as well. All of our chores have a linear execution path though.

8. A chore always consists of a single process which it is given the same name from. Do not use chores to group run processes as there is no error checking.

There is if you do it right. Our chore control cube has an element named "ContinueExecution". This is set to N in the Prolog of a process and only re-set to Y as the last thing in the Epilog. Each process beyond the first on checks that cell and if it's already N (because an earlier process failed to finish correctly), it won't execute. Each process also writes its completion information to the control cube so that we can identify where something failed.

Aside from which, those of us on a version which pre-dates ExecuteProcess don't have a choice.

9. TI variables should be named after the dimension being imported. v<variablename> could be used for user created variables certainly p<parametername> should be used for parameters. I would not be inclined to name variables with their type eg numeric/string/date.

I give source variables and parameters names indicating what they represent without any decoration. (Product, FiscalYear, whatever.) If I use "derived variables" (ones which are calculated) I use my version of VBA Hungarian notation as a mnemonic. (s_ for string, l_ for a (long) integer, dbl_ for a floating point; true, the last two have no system-based meaning within TI, but they're still useful to give me an "at a glance" idea of whether I'm dealing with a string, integer or decimal value).

[John Hammond]

Thanks Alan for your replies

Your point about Hungarian notation is a good one and, if VBA coders are used to it, it would make sense to continue the principle into TI.

I did not realise processexecute was such a recent thing and your error checking cube is a very good idea if you dont have the ability to examine a called process for a bad return code.

I have come up with a few more ideas for rules. Any comments welcome

R1. Large rules files need a numeric to link a rule with its feeders (applies to externally fed items also).

Code: Select all

feedstrings;
skipcheck ;
.
.
#99 
['Name' ] = s: if( ELLEV('Structure', !structure ) = 0,'Base',continue)  ;
['Name' ] = s: if( ELLEV('Structure', !structure ) = 1,'Middle',continue)  ;
['Name' ] = s: 'Top' ;
.
.
.
feeders ;
.
.
.
#99
['Empno'] => ['Name'] ;
 

R2. Continue to be used in if ...elseif...else constructs to avoid massive nesting of if statements as in the above example.


R3 and R4 probably need a bit of discussion

R3. Area notation to be used where possible on RHS of calc. (is DB notation simpler if you have to qualify everything with the dimension name)

R4. Fully qualified notation ie dimension:element to appear in area notation for large systems. (Where does large begin)

Any ideas appreciated.

[Steve Rowe]

It's an interesting area this one, well I'm not sure interesting is the word, but my feeling is that standards sometimes exist for their own sake and can often be restrictive for little return. My natural inclination is provided you document your code / rules well then you can adopt whatever conventions you are comfortable with.

An area that I feel quite strongly about is the naming of cubes and dimensions. TM1 is perhaps a little unusual in that it doesn't care about spaces and case in the naming of these objects. In addition the end-user is exposed to the object names on a day to day basis. For these reasons I like to call things what they actually are and avoid things like underscore.

Underscore is _horrible_ for the end user, by the time you have had to type it into an object name for 10th time on a Monday morning I feel rage. It's just an awkward character to get to and adds nothing to a TM1 system (IMO!). It also makes the server explorer look very "IT techy" and intimidates users. The same goes for CamelCase though to a lesser extent.

I think that developers lose sight of the fact that we build systems for end users and not so that they are easy to look after or so that some notional third party can look at the code and understand exactly what is happening. We should of course try and do both but in letting the secondary considerations outweigh the first we transfer problems to the end users who have to deal with those compromises every minute of every day.

To pick out some points on the rule side.

R1 I can remember discussing this in a past life and it's too simplistic, rules and feeders don't always come in matching sets. Your convention would need extending to cope with inter cube rules and feeders too. The danger is that this becomes a substitute for proper comments. (With apologies to everyone who has to follow my uncommented rule sets!)

R2 Not convinced that this should be a hard rule, what impact does the use of continue have on performance? There's also an assumption that the conditional logic is quite simple, if you need to test on more than one dimension continues not always efficient due to the need to repeat the conditional tests.

R3 I'd agree with the square bracket syntax is much easier to read, only DB where it is required.

R4 Not sure that this has a benefit, this is only required when non-unique elements exist in different dimensions. What's the advantage of including it?

I'm being quite negative about this but I just don't get trying to impose a set of arbitrary standards on TM1. Every system I've built has been different, even all the "standard" reporting and planning financial systems. There are of course things that are good practice programmatically like building and deleting views and subsets on fly within a TI process (subject to buggy releases of course).

If we want to get serious about best practice in rule writing we really need more information about the rules engine and calculation performance.

For example, which is better (gives the best response time) ?

['Name' ] = s: if( ELLEV('Structure', !structure ) = 0,'Base',continue) ;
['Name' ] = s: if( ELLEV('Structure', !structure ) = 1,'Middle',continue) ;
['Name' ] = s: 'Top' ;

or

['Name' ] = s: if( AttrN('Structure', !structure,'Level' ) = 0,'Base',continue) ;
['Name' ] = s: if( AttrN('Structure', !structure,'Level' ) =1,'Middle',continue) ;
['Name' ] = s: 'Top' ;

or

['Name' ] = s: if( AttrS('Structure', !structure,'Level' ) @= '0','Base',continue) ;
['Name' ] = s: if( AttrS('Structure', !structure,'Level' ) @='1','Middle',continue) ;
['Name' ] = s: 'Top' ;

or


['Name' ] = s: if( AttrN('Structure', !structure,'Level' ) = 0,'Base',
if( AttrN('Structure', !structure,'Level' )= 1,'Middle, 'Top'));

Does it matter how the attribute is derived?

Having said all that I do think TM1 suffers because there is no correct way of doing a lot of things. We can't resolve this by just picking a way though, we should be able to test and say definitively what the best approach is.

I'll shut-up now, sorry for the long post, stuck in a hotel room...

Cheers,

[Alan Kirk]

It's an interesting area this one, well I'm not sure interesting is the word, but my feeling is that standards sometimes exist for their own sake and can often be restrictive for little return. My natural inclination is provided you document your code / rules well then you can adopt whatever conventions you are comfortable with.

Until you get a very large code base, then return to a routine that was written 3 years ago, then have to read through the documentation to see which conventions the coder was comfortable with at the time that they wrote it and hope that they haven't made the documentation either too bloated to be clear, or have omitted something which seemed obvious to them at that time.

Orrrrr

You can develop a set of conventions, follow them, and know that whether the code was written 3 weeks or 3 years ago it will follow the same basic structure.

An area that I feel quite strongly about is the naming of cubes and dimensions. TM1 is perhaps a little unusual in that it doesn't care about spaces and case in the naming of these objects.

Now if only the operating systems and scripting languages that may need to interact with TM1 felt the same way.

In addition the end-user is exposed to the object names on a day to day basis. For these reasons I like to call things what they actually are and avoid things like underscore.

Underscore is _horrible_ for the end user, by the time you have had to type it into an object name for 10th time on a Monday morning I feel rage.

And the last time an end user typed the name of a cube, or dimension, or even an element as opposed to selecting it with a mouse was...?

Granted you can access a cube name in Sever Explorer by starting to type its name but unless you have a huge number of similarly named cubes you're going to hit the cube that you're after long before you hit the underscore character.

It's just an awkward character to get to and adds nothing to a TM1 system (IMO!). It also makes the server explorer look very "IT techy" and intimidates users. The same goes for CamelCase though to a lesser extent.

That would be mixed case. Camel case (at least in MS's interpretation of it (http://msdn.microsoft.com/en-us/library ... S.71).aspx)) doesn't have a leading capital, which is the part that I'd regard as pointless.

However given that this is 2010 and computers have been in the workplace for some 30-odd years now, if a user were to feel intimidated by a cube name like "Capex_Values" they may be better off seeking employment in a pianola or phonograph factory, or perhaps in chariot repairs.

I think that developers lose sight of the fact that we build systems for end users and not so that they are easy to look after or so that some notional third party can look at the code and understand exactly what is happening. We should of course try and do both but in letting the secondary considerations outweigh the first we transfer problems to the end users who have to deal with those compromises every minute of every day.

Given that users are often insulated from the code base by user interfaces like web pages or pre-formatted Excel reports, I don't feel that I for one am being too hard on them by designing the metadata in a way that means that it's not going to screw up the back end because the O/S or some script doesn't care for "huggable" characters like white spaces, or requiring objects to all be named with the word "My". The ones who do feel the need to poke around inside Server Explorer and create ad hoc reports, I would expect to have enough clues to be able to do that without being unduly intimidated by the absence of white space. See also, "2010, in use for 30 years".

[BariAbdul]

Hi Gurus,This is an old albeit an interesting post about TM1 objects naming conventions,Steve and Alan rightly do not like object with underscore for obvious reasons.
I have seen in my previous projects heavy use of underscore within dimension and cube name i.e sa_prod.But even getting rid of _ and simply using space (i.e sa prod )is not an alternative either.
In this perspective how gurus would approach this,Whether they will use
1.sa_prod
2.sa prod(blank)
3.SaProd

and what if the cube involved are staging cube or lookup cubes.It is tempting to do lk_paCube.
Appreciate your learned insights and best practices about naming conventions.Thanks a lot.

[Alan Kirk]

Hi Gurus,This is an old albeit an interesting post about TM1 objects naming conventions,Steve and Alan rightly do not like object with underscore for obvious reasons.

I think you are misreading what I wrote. Steve does not like underscores. I use underscores where necessary. I do NOT like white space (given the lack of consistency in handling it in most TM1 functions vs some TM1 string functions vs batch files) and I despise the use of anything that is not an alpha character, a numeric character or an underscore in object names because you won't know if doing so will blow up in your face until you're splashing water on the powder burns.

I have seen in my previous projects heavy use of underscore within dimension and cube name i.e sa_prod.But even getting rid of _ and simply using space (i.e sa prod )is not an alternative either.
In this perspective how gurus would approach this,Whether they will use
1.sa_prod
2.sa prod(blank) and get rid of blanks by substring and trim
3.SaProd

1 or 3 for me. The deciding factor would be whether the Sa part was intended to be just an abbreviation for a specific cube (in which case I'd be inclined to stick to mixed case) or whether the sa was intended to be, say, a "tag" representing a module name which groups related cubes together in the list. In the latter case I find that the use of an underscore separates the module tag from the cube's functional name more easily when I'm visually scrolling the cube list.

and what if the cube involved are staging cube or lookup cubes.It is tempting to do lk_paCube.
Appreciate your learned insights and best practices about naming coventions.Thanks a lot.

It's more common to use a "z" prefix on lookup and similar cubes, just to group them at the bottom. It's not required, and from the end user's point of view they won't know the difference if security for the cube is turned off anyway, but it makes the lookup and similar cubes easier to get to if you're an admin and can see all cubes regardless of security. It's not a mandatory thing but I think you'll find it to be very common.

[BariAbdul]

Thanks a lot Alan.Appreciate your precious time and help.