Naming of VIs and Controls in projects

[JDave]

I feel like I have used LabVIEW just long enough "to be dangerous". I remember when I first saw filenames from the OpenG toolkit and from different example code posted here on LAVA, that I thought the namespacing at the end of the filename was interesting and quaint. I have come to appreciate the utility of such standards as I have worked on some larger projects.

I have seen people use prefixes and suffixes to express certain qualities of a file - belonging to a group, private vs. public, functionality, global, etc. This makes looking through directories of files much easier and less painful. Not too mention avoiding unwanted cross-linking...

I like the style I see a lot here on LAVA -- filename__toolkit__project.vi

What styles do you use for naming files in your projects?

Curious,

David

[LAVA 1.0 Content]

What styles do you use for naming files in your projects?

I use LV 8.0.1 and 8.2. The new lvlib libraries and lvclass classes provide namespace for the items they contain. So I use these two to define the namespaces for my VIs.

[Jacemdom]

I feel like I have used LabVIEW just long enough "to be dangerous". I remember when I first saw filenames from the OpenG toolkit and from different example code posted here on LAVA, that I thought the namespacing at the end of the filename was interesting and quaint. I have come to appreciate the utility of such standards as I have worked on some larger projects.

I have seen people use prefixes and suffixes to express certain qualities of a file - belonging to a group, private vs. public, functionality, global, etc. This makes looking through directories of files much easier and less painful. Not too mention avoiding unwanted cross-linking...

I like the style I see a lot here on LAVA -- filename__toolkit__project.vi

What styles do you use for naming files in your projects?

Curious,

David

Here is a resume of the methodology i use.

I use a 3 part naming for functions and 2 parts for containers (globals, type defs, etc...) seperated by underscores.

The firts part is the nature of the file. The nature identifies the type of file. It answers to the question : What am I?

Functions

FVI=Flow VI

PVI=Polymorphic VI

CVI=Constant VI

UVI=User Interface VI

WVI=Wrapper VI(FVI ou SVI caller)

Containers

GLB=Global variable

TD=Type definition

STD=Strict type definition

RTM=Run-Time menu

The nature is or was there to permit further automation of code and build creation. Example : i could find all the dynamically called VIs just by looking on the front panels of the WVI files. All the communication with dynamically called VIs is done via this "wrapper" VI. All standard default files are FVI, only the exeptions get another name.

The second part is the domain. It identifies the data domain of the container or upon wich domain the functions act's on. It answers to the questions : What do i contain? (for containers) and On what do i act? (for functions)

Domains can include a hierarchy seperated by underscores ex: Motor_Axe_Speed. The first domain of a file in an app (not in shared libraries) is the app name. That way i never had name duplication issues. I also use an abreviation table in order to keep the file names not to long. Ex :Microsoft becomes MS, LabVIEW becomes LV.

The third part is for the functions and is the actual action of the function. It answers to the question : What do i do?

Examples :

MyApp folder could contain :

FVI_MyApp_Motor_Disable.vi

FVI_MyApp_Motor_Enable.vi

FVI_MyApp_Motors_Count.vi

FVI_MyApp_Motor_Speed_Set.vi

FVI_MyApp_Motor_Speed_Get.vi

FVI_MyApp_Motors_Speed_Set.vi

FVI_MyApp_Motors_Speed_Get.vi

TD_MyAPP (Contains TD_MyApp_Motor)

TD_MyApp_Motor

An example of my librarie :

FVI_MS_XL_Close.vi

FVI_MS_XL_Workbook_Close.vi

FVI_MS_XL_Workbook_Create.vi

FVI_MS_XL_Workbook_Worksheet_Create.vi

FVI_MS_XL_Workbook_Worksheet_Name_Set.vi

I'm currently fermenting how to merge it with the new LV8 implemented concepts. What i liked the most about that methodology is that the project folders where simple to follow.

A lot fermentation went into why to order nature_domain_action while almost everything that i saw was action_domain ex: get motor speed.vi and if you look at what it does in the folders is that it groups all the gets and sets and all other action together and if you put the domain in front of the action, all your files group automatically by domains and i like that better than the other way around. It also "Modularizes" the app without the need to add subfolders for smaller projects.

If someone would like to see the complete document(french) just ask.

For me :

filename__toolkit__project.vi would become project_toolkit_filename.vi

[crelf]

filename__toolkit__project.vi would become project_toolkit_filename.vi

I've got to agree on this methodology - put the class before the subclass (it's like when I was in the air force - no one asked supply for a blue short-sleeved shirt, we all requested a shirt short-sleeved blue ) It makes a lot of sense when categorizing your code. I'm also a fan of the dot model, so your example would become project.Toolkit.Filename.vi

[JDave]

For me :

filename__toolkit__project.vi would become project_toolkit_filename.vi

I've got to agree on this methodology - put the class before the subclass (it's like when I was in the air force - no one asked supply for a blue short-sleeved shirt, we all requested a shirt short-sleeved blue ) It makes a lot of sense when categorizing your code. I'm also a fan of the dot model, so your example would become project.Toolkit.Filename.vi

I agree that having a class before subclass is good, but it is slightly modified for me. I have tended to have some of the different functionality broken out into subdirectories, so I haven't worried about having a naming scheme to keep them straight. I don't do OOP in LabVIEW yet, but I use an architecture with several autonomous agents that are class-like. I name any subVIs belonging to these top-level VIs with a prefix describing who they belong too. I use a separate prefix to label top level (agent) VIs. So files either belong to an agent, or they belong "Top Level", or they simply belong to the project and have no prefix. This gives some sense of public and private scope.

My thoughts with the toolkit were more along the lines of a reuse library used in a project. An error handling library may have a suffix of __err. If you import this library into your project (either to maintain modularity or due to some project specific VIs in the library) then the namespace would be __err__proj.

I like the idea of a file type prefix. I used a TD prefix on my typedefs for a while, though I have recently just placed them in a Typedef subdirectory and left off the prefix. I still don't know which I prefer. I have tried having the project as a prefix, but I didn't like it. All the files in a directory should belong to the same project so the files aren't grouped by the prefix. It seemed to be harder to search through the directory because my brain had to continually skip over the first part of the filename.

So more precisely, my current method looks like :

• scope - functionality__project.vi
  
• functionality__toolkit__project.vi
  

David

P.S. - Having a consistent scheme definitely allows for some nice automation and scripting options.

[Mike Ashe]

(it's like when I was in the air force

A wing-washer huh? Us squids in the silent service used the same basic nomenclature, but you forgot the "one, each" at the end of the order.

- no one asked supply for a blue short-sleeved shirt, we all requested a shirt short-sleeved blue ) It makes a lot of sense when categorizing your code.

I'm also a fan of the dot model, so your example would become project.Toolkit.Filename.vi

I personally like the dot model, a lot, but I have been burned a couple of times bringing in a plugin manager and dynamic loading of code to a new client only to have their code and mine not play nice together initially because some of their code was based on replacing what they thought were suffixes like .log or .vi with something else and they didn't anchor their regular expressions to the correct end of the string / VI names, they just split & replaced at the first period they found, argghh ...

[i2dx]

I use prefixes:

PROJECT_FUNCTION GROUP_vi-name.vi

e.g.

LV82TPL11_SQL_select whatever data.vi --> select some Data from the Database with

LV82TPL11_DLG_the dialog name.vi --> a dialog VI, that pops up

I was considering to give up that practice with LV 8.20, because you have the Project Manager and LVLIBS, but I did not, because, I am used to it, you can see immediately to which project a file belongs, If you see it in the windows explorer -

and it makes my Project Copy tool faster : If I start with I new project, I use my tool to copy the entire hierarchy of my Project template into a new folder with a new prefix and can start developing immediately. It's a little bit like the solution wizard in Visual Studio. If you click there e.g. "Windows Application" all the files, you need are created automatically ...

cheers,

CB

[JDave]

I appreciate the responses. I never did hear from anybody that uses suffixes to namespace, though the OpenG VIs support mangling and unmangling of VI filenames with suffixes. Do people just not use this any more?

David

[Jim Kring]

I appreciate the responses. I never did hear from anybody that uses suffixes to namespace, though the OpenG VIs support mangling and unmangling of VI filenames with suffixes. Do people just not use this any more?

David

We (OpenG and also within JKI) use the suffix (mangling) during the library build/package process (the suffix is applied at build time, prior to deployment). For project VIs we generally apply a prefix for each class/subsystem/library.

[JDave]

We (OpenG and also within JKI) use the suffix (mangling) during the library build/package process (the suffix is applied at build time, prior to deployment). For project VIs we generally apply a prefix for each class/subsystem/library.

I always wondered why Commander had OGC in the prefix and the suffix.

I can understand the helpfulness of mangling at deployment, but what help is it to put the project name at the beginning of the filename? If I remember right (I can't check since I have VIPM installed already :worship: ) the OGC and OGPM portions were in different directories. If there is no need to organize by the prefix, and you have the files in a project directory, then what does the project prefix gain you?

I like the prefix for a class/subsystem/library, no need for there.

David

[Jacemdom]

If there is no need to organize by the prefix, and you have the files in a project directory, then what does the project prefix gain you?

I like the prefix for a class/subsystem/library, no need for there.

David

Could be to avoid names collisons in LV memory? I use prefixes all the time even tough when there is a large number of VIs i put them in a subfolder, to avoid same name issues in LV, but also in my library. Everyone as a unique name and that way everyone is recognizable by it.