Library & Class Naming Convention Advice

[MartinMcD]

Can anyone offer advice on successful naming conventions for libraries & classes and their members and properties please? Eg camel case, spaces, prefixes, abbreviations etc.

I need to settle down into a better pattern not least to reduce the number of times I want to change the name and run into SCC problems.

Thank you,

Martin

[shoneill]

One major thing is simply to have a convention and write it down.  I'm not aware of one convention to rule them all so to speak.

 

I tend to name accessors Set and Get instead of Read and Write because Set and Get have the same Nr. of Characters.  When listed in detailed view, they seem easier to read for me.

[LogMAN]

One major thing is simply to have a convention and write it down...

 

shoneill is right, having a convention is a very important thing. ( I used to change my 'convention' because of various, situational and sometimes stupid reasons, so code got messy or time run out )

 

There are some things to consider, this is what I could guess of (speaking in general, not specifically for libraries or classes):

 

Prefixes -> Use libraries/classes instead (you'll get a namespace 'Library.lvlib::Member.vi'), how would that look with prefixes: 'prefix_Library.lvlib::prefix_Member.vi' ( )... You have to organize the files on disk to prevent name conflicts though. If there is a need to prefix everything, just change the library/class name (linking issues are conveniantly easy to solve this way in my experience).

Spaces -> One of the most obvious things that make LabVIEW different to languages like C. Good for starters and easy to read. However if you build DLL files (or enable ActiveX afaik), spaces are a problem.

CamelCase -> Sometimes hard to read and maintain, but in combination with libraries the most flexible one in my opinion. Makes it easier to reason with people from the other side.

 

CamelCase in combination with libraries/classes is what I actually use, even though it is sometimes painfull to stick to ( ever batch-created accessor VIs to class members? I'm always having fun renaming all of them ).

 

As you're asking for libraries & classes specifically, I don't use prefixes (they tend to change on my end...) and I have trouble to write well-named VIs including spaces (would you write 'Write to Disk' or 'Write To Disk'? Therefore CamelCase is a good solution for me ( 'WriteToDisk' ). I also no longer create subfolders on disk to organize class files, but virtual folders in the project only (how I hated to move files because they are in a different category for some stupid reason...). Also libraries (*.lvlib) and class (*.lvclass) files are within their particular subfolder on disk. If I now move a library/class to a different section, I just have to drag the entire folder. This handles quite well in SVN too.

 

Would be interesting to see how everybody else handles such things...

 

EDIT: Error in database, but still posted?

Sorry for this tripple-post.

Edited February 7, 2014 by LogMAN

[PaulL]

The naming policy we have adopted is as follows:

 

We use UpperCamelCase for class and library names, as well as controls.  We use lowerCamelCase for attributes and methods.  We do not allow spaces.

 

[The accessor methods LabVIEW autogenerates follow different rules, and we allow that.  (I'm not sure if this is customizable or not.)

Also, we allow exceptions for cluster elements that appear on user interfaces.  These have Friendly Names With Spaces.  (It is possible to have a caption this way and have lables that follow our other rules, but this is more work than it is worth.]

[todd]

Prefixes -> Use libraries/classes instead (you'll get a namespace 'Library.lvlib::Member.vi'), how would that look with prefixes: 'prefix_Library.lvlib::prefix_Member.vi' ( )... You have to organize the files on disk to prevent name conflicts though. If there is a need to prefix everything, just change the library/class name (linking issues are conveniantly easy to solve this way in my experience).

"Me, too", on this one. lvlib for namespacing and encapsulation. Short names for each class and method. One file-system folder per class and it's methods. Virtual folders for grouping by functionality within classes and libraries.

[MarkCG]

Prefixes -> Use libraries/classes instead (you'll get a namespace 'Library.lvlib::Member.vi'), how would that look with prefixes: 'prefix_Library.lvlib::prefix_Member.vi' ( )... You have to organize the files on disk to prevent name conflicts though. If there is a need to prefix everything, just change the library/class name (linking issues are conveniantly easy to solve this way in my experience).

Spaces -> One of the most obvious things that make LabVIEW different to languages like C. Good for starters and easy to read. However if you build DLL files (or enable ActiveX afaik), spaces are a problem.

CamelCase -> Sometimes hard to read and maintain, but in combination with libraries the most flexible one in my opinion. Makes it easier to reason with people from the other side.

Can't agree more with this. I find libraries full of VIs prefixed with the library name really annoying because the unnecessary duplication, and it makes it difficult to pick out the actual VI name when looking at the title bar. And if you are sticking members of different libraries in the exact same folder to where you NEED prefixes, may God help you... Edited February 7, 2014 by MarkCG

[GregFreeman]

One major thing is simply to have a convention and write it down.  I'm not aware of one convention to rule them all so to speak.

 

I tend to name accessors Set and Get instead of Read and Write because Set and Get have the same Nr. of Characters.  When listed in detailed view, they seem easier to read for me.

I agree with the get and set just because often I'm dealing with hardware and something like Read <name> I feel implies actual communication with the device where Get <name> implies an accessor (as it commonly does in other languages as well). In fact, I wish they'd change the default name to get and set when creating/savings accessors. 

 

One follow on I'd like to ask is how you guys handle naming of methods when public/private have the same name. For instance, I may have a public method called "Read Device" which really just sticks a message in a queue, and then a private "read device" method that does the actual work. But if I name them the same they can't be in the same directory on disk. So now this gets into directory hierarchies on disk which may be a whole different animal. Thoughts?

[LogMAN]

One follow on I'd like to ask is how you guys handle naming of methods when public/private have the same name. For instance, I may have a public method called "Read Device" which really just sticks a message in a queue, and then a private "read device" method that does the actual work. But if I name them the same they can't be in the same directory on disk. So now this gets into directory hierarchies on disk which may be a whole different animal. Thoughts?

 

The easiest solution would be to rename the private method to "PrivateReadDevice.vi", as the private interface can still be changed anytime without side effects on implementations (like linking issues).

 

However your example should be two seperate classes in my opinion:

One for serialized access (i.e. the implementation of a driver) and a second class for access in terms of a messaging system to an async. state-machine/process which implements the driver.

[Neil Pate]

In fact, I wish they'd change the default name to get and set when creating/savings accessors. 

You know you can customise this to whatever suits you right?

 

Edit CLSUIP_LocalizedStrings.vi in LabVIEWresourceFrameworkProvidersLVClassLibraryNewAccessors and change the Write and Read to whatever suits you. Don't forget to right-click-->make the value default on each of the string controls after you have changed it, and then save.

 

Only pain point here  is that it has to be done for each new LV installation

[GregFreeman]

The easiest solution would be to rename the private method to "PrivateReadDevice.vi", as the private interface can still be changed anytime without side effects on implementations (like linking issues).

 

However your example should be two seperate classes in my opinion:

One for serialized access (i.e. the implementation of a driver) and a second class for access in terms of a messaging system to an async. state-machine/process which implements the driver.

Oh, I do but my "actor" will hold that device driver in its private data and sometimes rather than unbundling the device specific class from the actor and doing the work right on the actor's block diagram where the message comes in, I will put the delegation/unbundling to the specific driver in a private subVI of the actor and pass in the message data. This gives me a subVI per message received in the Actor. Maybe is an unnecessary wrapper, but for one reason or another I have been known to do it. If it's a bad habit or obfuscates things (which it may), please let me know. It is a habit that can be easily broken.

 

 

You know you can customise this to whatever suits you right?

Now I do! 

Edited February 8, 2014 by GregFreeman

[MartinMcD]

Thanks for all these comments, its great input for me.