I'm currently writing a coding guideline and it would be nice to get your input on what you call your timers. For example, when you declare an instance of TON. Is it something like "ton_TimeoutPump1"? Or do you skip the prefix?
Kristian Berlin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the V3 CAA Library design the following is advised:
Function block instances and variables of user-defined data types as a prefix have to get a short
identifier for the FB- resp. data type name (Example: sdo).
Example:
sdoReceivedTelegram: CAN_SDOTelegram;
tonPump1Timeout would be good an clear name for your FB instance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hope you are well!
There is the design advice, but sometimes it's one thing what is advised and one thing what people actually do. Do you follow this advice yourself and use prefixes like "ton", "ctu" and "pid"?
/Kristian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't use to do it this way, but I noticed it is very clear if other programmers/customers want to understand the application or example. Most of the time you just look at the code to find out how something works. You don't want to go to the variable list to find out what type it is.
Besides this the namespacing in V3 libraries, use of the scope (gvl.xxx) and structures give the variables and FB instances clear and understandable names.
Tim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you can share the guide I am very interested. I started my own CoDeSys guidelines. I am not a big supporter of the one page naming conventions of 3S. One thing to look out for. In V2.3 the name of your function block assuming camel case might be MyFunctionBlock and appears that way as the object name of the block. In V3 all Functions and FB become capitalized so in V3 it looks like this MYFUNCTIONBLOCK.
What should be in place is a table of acronyms/abbreviations so that in the naming convention they can be used and understood by all. Like reset is rst, Power is pwr, timer is tmr etc.. It would be great if it were universal. Where does the timer abbreviation get inserted in the naming convention? I would suggest the end since it can be an optional value. So a FB naming convention might be CamelCase_Option so OxygenTank1_Tmr. Then it may also depend on the scope of the variable.
I can share my document with you as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm currently writing a coding guideline and it would be nice to get your input on what you call your timers. For example, when you declare an instance of TON. Is it something like "ton_TimeoutPump1"? Or do you skip the prefix?
Kristian Berlin
Hi Kristian,
According to the V3 CAA Library design the following is advised:
Function block instances and variables of user-defined data types as a prefix have to get a short
identifier for the FB- resp. data type name (Example: sdo).
Example:
sdoReceivedTelegram: CAN_SDOTelegram;
tonPump1Timeout would be good an clear name for your FB instance.
Hi Tim,
Hope you are well!
There is the design advice, but sometimes it's one thing what is advised and one thing what people actually do. Do you follow this advice yourself and use prefixes like "ton", "ctu" and "pid"?
/Kristian
Hi Kristian,
I didn't use to do it this way, but I noticed it is very clear if other programmers/customers want to understand the application or example. Most of the time you just look at the code to find out how something works. You don't want to go to the variable list to find out what type it is.
Besides this the namespacing in V3 libraries, use of the scope (gvl.xxx) and structures give the variables and FB instances clear and understandable names.
Tim
If you can share the guide I am very interested. I started my own CoDeSys guidelines. I am not a big supporter of the one page naming conventions of 3S. One thing to look out for. In V2.3 the name of your function block assuming camel case might be MyFunctionBlock and appears that way as the object name of the block. In V3 all Functions and FB become capitalized so in V3 it looks like this MYFUNCTIONBLOCK.
What should be in place is a table of acronyms/abbreviations so that in the naming convention they can be used and understood by all. Like reset is rst, Power is pwr, timer is tmr etc.. It would be great if it were universal. Where does the timer abbreviation get inserted in the naming convention? I would suggest the end since it can be an optional value. So a FB naming convention might be CamelCase_Option so OxygenTank1_Tmr. Then it may also depend on the scope of the variable.
I can share my document with you as well.