Jump to content

Naming of VIs and Controls in projects


JDave

Recommended Posts

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

Link to comment
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

Link to comment
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

Link to comment
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. :shifty:

Link to comment
(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. :P
- 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 ...

Link to comment

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

Link to comment
  • 3 weeks later...
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.

Link to comment
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 post-949-1161013581.gif there.

David

Link to comment
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 post-949-1161013581.gif 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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.