Page 1 of 1

TM1 Coding Standards

Posted: Wed Jan 15, 2025 9:45 pm
by mukeshrajdass
Hi

I just want to get an opinion from the more experienced TM1 developers/coders....i am doing some remote work for a Dubai based construction company from Australia. I have this consultant from an Indian IT firm telling me to change my coding standard to follow the organisation standard. No information provided. I find it extremely hard to understand and accept that this is the CODING STANDARD !! Reluctantly, I have changed it...i just want to get an opinion on what you would have done in my place. I do not have access to the so-called Coding Standard official or otherwise.

Here are examples of my codes and what i am told to modify to... what would you do in my place ? I am told to create unnecessary spaces etc

Replaced some codes with 'xxx' for privacy reason.

Code: Select all

----------------------------------------------My Code (spaces in dots)
dm = 'RFI XML ID Temp';
IF(Dimix(dm,v_RFI_IdNum) = 0);
...DimensionElementInsert(dm,'',v_RFI_IdNum,'S');
ENDIF;

sDim = 'RFI XML ID';
IF ( DIMIX( sDim, v_RFI_IdNum ) = 0);
 ...DimensionElementInsert(sDim,'',v_RFI_IdNum,'S');
ENDIF;
----------------------------------------------------Modified To
sDim = 'AU Sample RFI';
        IF ( DIMIX( sDim, v_RFI_IdNum ) = 0);
             DimensionElementInsert(sDim,'',v_RFI_IdNum,'S');
        ENDIF;

sDim = 'RFI XML ID';
        IF ( DIMIX( sDim, v_RFI_IdNum ) = 0);
             DimensionElementInsert(sDim,'',v_RFI_IdNum,'S');
        ENDIF;




----------------------------------------------My Code (spaces shown as dot)
sJuris_Sub = 'CP_Sample_Jurisdiction';

IF( SubsetElementExists( sJurisdiction | ' Reportable Jurisdiction', sJuris_Sub, v_Reportable_Jurisdiction ) =0 );
...SubsetElementInsert( sJurisdiction| ' Reportable Jurisdiction', sJuris_Sub, v_Reportable_Jurisdiction,1 );
ENDIF;
----------------------------------------------- Modified Ton (unnecessary spaces)
sJuris_Sub = 'CP_Sample_Jurisdiction';

..spaces.. IF( SubsetElementExists( sJurisdiction | ' Reportable Jurisdiction', sJuris_Sub, v_Reportable_Jurisdiction ) =0 );
..spaces..... SubsetElementInsert( sJurisdiction| ' Reportable Jurisdiction', sJuris_Sub, v_Reportable_Jurisdiction,1 );
--spaces...ENDIF;
#-------------------------------------


----------------------------------------------My Code (spaces shown as dots)
vdm= sDim_Temp;
IF(DimensionExists(vdm)=1);
...DimensionDestroy(vdm);
endif;
vdm = sDim_Temp1;
IF(DimensionExists(vdm)=1);
...DimensionDestroy(vdm);
endif;
vdm = sDim_Temp2 ;
IF(DimensionExists(vdm)=1);
...DimensionDestroy(vdm);
endif;
vdm =  sDim_Temp4;
IF(DimensionExists(vdm)=1);
...DimensionDestroy(vdm);
endif;
-----------------------Modified To (unnecessary spaces shown with dots)
sDim_Temp= sDim_Temp;
....IF(DimensionExists(sDim_Temp)=1);
.......DimensionDestroy(sDim_Temp);
....ENDIF;

sDim_Temp = sDim_Temp1;
....IF(DimensionExists(sDim_Temp)=1);
.......DimensionDestroy(sDim_Temp);
....ENDIF;

sDim_Temp = sDim_Temp2 ;
....IF(DimensionExists(sDim_Temp)=1);
.......DimensionDestroy(sDim_Temp);
....ENDIF;

sDim_Temp =  sDim_Temp3;
....IF(DimensionExists(sDim_Temp)=1);
.......DimensionDestroy(sDim_Temp);
....ENDIF;

Re: TM1 Coding Standards

Posted: Wed Jan 15, 2025 10:09 pm
by ascheevel
I see things that upset me in both your original and the modified snippets, but if I had to pick which one I'd rather read, I'd pick the modified. Personally, I don't add spaces around a parenthesis, but I like to see consistency no matter what a developer decides they want to do with spaces. I like the updated variable naming convention better than your original; I also like the single blank rows between sections. I loathe the fact that neither before/after have any sort of tabbing. I also prefer to add a space after a comma, you sometimes do that and sometimes not. Whatever standard you use, just be consistent! Remember, code needs to be readable, especially to someone other than the person who wrote it.

Hard to say what I would do in your place. I've had clients who like to see things done a certain way and I modify my style to fit that if I'm not too offended by their preference. Even when I'm bothered by it, it's sometimes not worth the effort to try to show them a better style, particularly if you're only working on a few items over a short period of time. Usually though, I'm working with people that understand that everyone has their own unique coding style and as long as stuff is still readable, is performant, and doesn't violate reasonable style expectations, no one gets upset about it. Looking at your code and the updated, I don't think all the expectations are unreasonable if the consultant is actually in a position of authority to dictate the standard.


edit: I see you've added dots to represent spaces, I retract my loathsome statement. Why not put your code in code blocks?

Re: TM1 Coding Standards

Posted: Thu Jan 16, 2025 3:21 am
by mukeshrajdass
Don't normally use this forum....not sure where i need to do this..

Re: TM1 Coding Standards

Posted: Thu Jan 16, 2025 5:57 am
by Alan Kirk
ascheevel wrote: Wed Jan 15, 2025 10:09 pm edit: I see you've added dots to represent spaces, I retract my loathsome statement. Why not put your code in code blocks?
mukeshrajdass wrote: Thu Jan 16, 2025 3:21 am Don't normally use this forum....not sure where i need to do this..
Select your code, then hit the icon that looks like this: [</>] as shown below. It works the same in any phpBB forum like this one, as well as in some applications like Slack. It ensures that the rendered text doesn't ignore spaces, tabs or other indentation code, as well as presenting it in a fixed width font. I've done it for you in this case:
2025-01-16_16-52-36_CodeBlock.jpg
2025-01-16_16-52-36_CodeBlock.jpg (107.51 KiB) Viewed 7684 times

Re: TM1 Coding Standards

Posted: Thu Jan 16, 2025 8:22 am
by MarenC
Hi,

I like to be consistent with coding, so parameters are prefixed with p, strings with s, numeric with n, process variables with v etc etc.

You could take it further and distinguish between constant variables and variables whose values change.

Present the code so it is readable, i.e. indented, appropriate spacing etc.

One thing I think often gets overlooked when considering coding standards is debugging code.

I see overuse of variables as an issue here because you can be constantly toing and froing between parts of code to see what the variable is referring to.

Also if you want to do powershell searches for let us say, where an element is used in processes, then only include the element name in the process if it is actually being used by that process.

Maren

Re: TM1 Coding Standards

Posted: Thu Jan 16, 2025 9:44 am
by gtonkin
Going to echo Maren here - I think I largely follow what Bedrock is doing by coincidence and because it makes sense to have p for parameters etc.

I also used to be really excited to put everything in a variable, sCube=this and sCube=that etc. just in case you need to update it later.
Never happens as the likelihood of the process switching cubes is almost zero, and if you do, search and replace.

All it has seemed to do is frustrate the debugging efforts over the years "constantly toing and froing between parts of code to see what the variable is referring to."

Right now I am training newcomers to reference the objects by strings so that you can read it i.e. CellPutN(nValue, 'Expense',...);
Using CellPutN(nValue, sCube.Target,...); or worse CellPutN(nValue, sCube2,...); just seems to frustrate the initial coding and later debugging, especially by someone who did not write the code.

Another maybe more subtle one that not everyone will agree with is I tend to break statement across multiple lines, especially when we have a MUN or fully qualified name in a rule. Rules trailing across the screen just seem antiquated, hit enter, it indents and you can read it.

Similarly with TI and Execute/RunProcess. I find it easier to have the parameter and value pairs on their own line. Easier to flow your eyes down the screen than off into the right margin.

Because I largely use PAW and some ARC, I always indent, just feels right and if you do start with TM1Py and python you will need to get into this habit fast.

In terms of commentary, someone once said to me that if you lost all your code but had your comments would you be able to rewrite the process again?
I may overdo comments but they often save the day when someone asks about an odd exception or a piece of code that seems to make no sense, until you read the comment.

HTH

Re: TM1 Coding Standards

Posted: Thu Jan 16, 2025 8:41 pm
by mukeshrajdass
Thank for the feedback guys...much appreciated

Re: TM1 Coding Standards

Posted: Fri Jan 17, 2025 9:34 am
by lotsaram
    gtonkin wrote: Thu Jan 16, 2025 9:44 am I also used to be really excited to put everything in a variable, sCube=this and sCube=that etc. just in case you need to update it later.
    Never happens as the likelihood of the process switching cubes is almost zero, and if you do, search and replace.

    All it has seemed to do is frustrate the debugging efforts over the years "constantly toing and froing between parts of code to see what the variable is referring to."
    I also think that over-declaring constants is a cancer which only makes code less transparent. But my grey line is somewhere else, I would always have a constant declared for cCubTgt, cCubSrc, etc. I'm always using Arc and not Workbench so this doesn't lose any transparency as with a mouse hover on any variable or constant I can see the assigned value. But I would certainly not have a constant declared for every single different measure in a block of 20 CellPutNs for example. This doesn't make sense to me and irritates when I come across it in someone else's code.