Naming Conventions and Project Organization

[Daryl]

I would like to settle an issue that has been driving me crazy for a while now - naming conventions. Everyone has their own method around here and I would like to standardize it (or at least get the conversation started about standardizing it) I am talking about Project names, VI names, SubVI, signals, globals, etc. Would anyone like to share or discuss their method?

While we are at it, I would like to come up with a standard Labview Project "layout" (at least to be used as a starting point) I'm tired of custom controls, subvi's, etc.. being scattered all over the place in different subfolders that are not intuitive to locate. How do you all organize your files in your project/on disk? I will try to post a screenshot of my current layout and open it up for discussion a little later.

[PaulG.]

Naming conventions are up to you and your team - and as you will see here you will get just as many suggestions as folks who respond. Good luck with that.

One thing I have learned, however, and it could be useful for you: don't keep a seperate folder for typedefs and custom controls. Put these in the code directories. It will make things a lot easier if you ever want to reuse your code somewhere else.

[Shaun Hayward]

There is an example project directory template available as a download from the Bloomy Controls LabVIEW Style Book Companion Website (www.bloomy.com/lvstyle) that could give you a starting point.

Edited September 25, 2009 by Shaun Hayward

[Mark Yedinak]

While I applaud your desire to see things standardized I don't think you will ever be able to accomplish this. Each project is unique and the project itself may very likely impose a naming convention on it. There never will be a "one size fits all" solution for something like a naming convention.

[Rolf Kalbermatter]

I would like to settle an issue that has been driving me crazy for a while now - naming conventions. Everyone has their own method around here and I would like to standardize it (or at least get the conversation started about standardizing it) I am talking about Project names, VI names, SubVI, signals, globals, etc. Would anyone like to share or discuss their method?

While we are at it, I would like to come up with a standard Labview Project "layout" (at least to be used as a starting point) I'm tired of custom controls, subvi's, etc.. being scattered all over the place in different subfolders that are not intuitive to locate. How do you all organize your files in your project/on disk? I will try to post a screenshot of my current layout and open it up for discussion a little later.

As others have said you can do that for yourself and your team (if you have any decision power there) but trying to get other people to follow your ideas is very surely doomed. This is a problem in any programming environment and one there is no real solution other than restricting your desire to standardize to the group of people you have power to tell what they have to do.

In standard programming languages this starts for instance at indention, bracket styles, UpPeR/LoWeRcAsE, naming conventions, etc and goes further over what types of elements are allowed respectively required. Most Open Source projects try to have a more or less strongly recommended style but seldom enforce it very strictly unless in those projects where committing power is restricted to one or two "benevolent" dictators.

So in short, discussion is fine, but accept that everybody who has been working in LabVIEW for a while, has his own style and is very unlikely to be convinced that someone elses style is better.

Rolf Kalbermatter

[Dan DeFriese]

My preference is:

1) Each module (group or related VIs and CTLs) to have its own folder on disk.

2) All VIs and CTLs are contained in that folder (no subfolder).

3) Any further organization is done using *Virtual Folders in the .lvproj and .lvlib files (no autopopulating for me).

4) Control file names are ALL_CAPS_WITH_UNDERSCORE.

5) VI file names are Title_Text_With_Underscore.

6) VI and Control filenames have a acronym suffix to identify its owning module.

If you don't do it this way go fly a kite!!!

Honestly though, I don't think its all important that everybody origanize their code the same way. There are 6 developers on my team and not a single one of us codes the same way, much less organizes files the same way.

I think its much more important that you are consistant in what you do. As long as a developer is consistant (does the same things in similar fashion throughout the project) it will work out so I can navigate the project after the few minutes it takes to get my bearings.

*I really like Virtual Folders since they allow me order the files any way I want, move stuff around, or remove obsolete code without have to mess with disk or source control content.

[Mark Yedinak]

Honestly though, I don't think its all important that everybody origanize their code the same way. There are 6 developers on my team and not a single one of us codes the same way, much less organizes files the same way.

I think its much more important that you are consistant in what you do. As long as a developer is consistant (does the same things in similar fashion throughout the project) it will work out so I can navigate the project after the few minutes it takes to get my bearings.

*I really like Virtual Folders since they allow me order the files any way I want, move stuff around, or remove obsolete code without have to mess with disk or source control content.

I think it is important for a single project to keep things consist. So if you have multiple developers on a single project everyone should agree how things are done on that project. If everyone is working individually then there isn't an issue if everyone has their own style but it can be problematic if there are multiple styles on a single project.

[Daklu]

Everyone has their own method around here and I would like to standardize it

Heck, I can't even settle on a naming convention for my own stuff. Sometimes my sub VIs names have spaces, sometimes I use PacalCase. Sometimes I'll use dot notation in the name to help describe the purpose of a given VI. (VirtualNamespace.SubVi1) Sometimes my abstract base classes are appended with "Abstract," sometimes they aren't. Sometimes my base classes are appended with "Base," sometimes not. I just haven't found any general rule I'm completely comfortable with yet. About the only positive I can give is that my naming is generally consistent within a specific project. When comparing different projects all bets are off.

[Daryl]

Heck, I can't even settle on a naming convention for my own stuff. Sometimes my sub VIs names have spaces, sometimes I use PacalCase. Sometimes I'll use dot notation in the name to help describe the purpose of a given VI. (VirtualNamespace.SubVi1) Sometimes my abstract base classes are appended with "Abstract," sometimes they aren't. Sometimes my base classes are appended with "Base," sometimes not. I just haven't found any general rule I'm completely comfortable with yet. About the only positive I can give is that my naming is generally consistent within a specific project. When comparing different projects all bets are off.

I hope I didn't come off sounding like some sort of dictator wanna-be in my original post but we have a real issue here that I need to get my hands around somehow (and really no power to do it).

There are people using something like "pwr_wdw_down" for an ignition input signal. People make subvi's for no apparent reason. I have tried to get everyone to use SCC but they are too lazy to learn/use it and I'm sure most of you are familiar with what you end up with if you are not well organized. We have many copies of projects all over different drives and no one can say what is the latest version or what the difference between project "AAAA123" and project "AAA123" is. (yes, they keep tacking more A's to the front to get it to the top of a folder when browsing in explorer.) I couldnt tell you what a project or a file is just by looking at the name of it. In some projects, everything is crosslinked to different folders/projects and it is way out of hand. I could go on all day long describing some of these horrors.

The real problem is, they took a group of engineers and said - you are now part of an eCAE team responsible for testing, simulation, and rapid prototyping (of ECU modules) These engineers (and I use that term loosley) have no software engineering background and too stubborn to admit they dont know the correct way to do something or ask for help. We use many different softwares including Labview. I have the most experience with Labview and my hope is to at least get this portion of my groups responsibilites in order hoping that it will "rub off" into the other areas and software projects. I need to find one little corner to start in and hope it will spread but its like talking to a wall.

Ok, I'm done venting for now.

[PaulG.]

I hope I didn't come off sounding like some sort of dictator wanna-be in my original post but we have a real issue here that I need to get my hands around somehow (and really no power to do it).

There are people using something like "pwr_wdw_down" for an ignition input signal. People make subvi's for no apparent reason. I have tried to get everyone to use SCC but they are too lazy to learn/use it and I'm sure most of you are familiar with what you end up with if you are not well organized. We have many copies of projects all over different drives and no one can say what is the latest version or what the difference between project "AAAA123" and project "AAA123" is. (yes, they keep tacking more A's to the front to get it to the top of a folder when browsing in explorer.) I couldnt tell you what a project or a file is just by looking at the name of it. In some projects, everything is crosslinked to different folders/projects and it is way out of hand. I could go on all day long describing some of these horrors.

The real problem is, they took a group of engineers and said - you are now part of an eCAE team responsible for testing, simulation, and rapid prototyping (of ECU modules) These engineers (and I use that term loosley) have no software engineering background and too stubborn to admit they dont know the correct way to do something or ask for help. We use many different softwares including Labview. I have the most experience with Labview and my hope is to at least get this portion of my groups responsibilites in order hoping that it will "rub off" into the other areas and software projects. I need to find one little corner to start in and hope it will spread but its like talking to a wall.

Ok, I'm done venting for now.

Jeepers. You sound like you are living a nightmare. I don't know who is in charge over there but he/she needs to get involved NOW bringing these projects and programmers under control. Naming conventions are the least of your concerns.

[Rolf Kalbermatter]

I hope I didn't come off sounding like some sort of dictator wanna-be in my original post but we have a real issue here that I need to get my hands around somehow (and really no power to do it).

There are people using something like "pwr_wdw_down" for an ignition input signal. People make subvi's for no apparent reason. I have tried to get everyone to use SCC but they are too lazy to learn/use it and I'm sure most of you are familiar with what you end up with if you are not well organized. We have many copies of projects all over different drives and no one can say what is the latest version or what the difference between project "AAAA123" and project "AAA123" is. (yes, they keep tacking more A's to the front to get it to the top of a folder when browsing in explorer.) I couldnt tell you what a project or a file is just by looking at the name of it. In some projects, everything is crosslinked to different folders/projects and it is way out of hand. I could go on all day long describing some of these horrors.

The real problem is, they took a group of engineers and said - you are now part of an eCAE team responsible for testing, simulation, and rapid prototyping (of ECU modules) These engineers (and I use that term loosley) have no software engineering background and too stubborn to admit they dont know the correct way to do something or ask for help. We use many different softwares including Labview. I have the most experience with Labview and my hope is to at least get this portion of my groups responsibilites in order hoping that it will "rub off" into the other areas and software projects. I need to find one little corner to start in and hope it will spread but its like talking to a wall.

Ok, I'm done venting for now.

Aaah well that clears up a lot. It sounded a bit like you wanted to try to tell everybody on LAVA how to do things . And that is something doomed to fail, because after all we are LabVIEW Advanced Virtual Architects and no advanced guy/gal accepts someone else trying to tell him/her how to do things the right way.

In your situation even if you are in a position where you have the powers to force people into doing something, the best thing would be education. Try to establish some training sessions. Nothing fancy or to formal but something like half an hour each week where you get all the people together and then show them some means to get well organized. Get it interactive, and let them workout the solutions you want them to learn. Make from a group of individual fighters a real team.

And most important don't expect this to change everything in two weeks. Be persistent but without being notorious. It will not change after the first time, and only slightly after the 5th. But there will be change over time and as people see that it is more effective to do the things in a somewhat more organized way it will without doubt have an impact.

Rolf Kalbermatter

[Mark Yedinak]

I hope I didn't come off sounding like some sort of dictator wanna-be in my original post but we have a real issue here that I need to get my hands around somehow (and really no power to do it).

There are people using something like "pwr_wdw_down" for an ignition input signal. People make subvi's for no apparent reason. I have tried to get everyone to use SCC but they are too lazy to learn/use it and I'm sure most of you are familiar with what you end up with if you are not well organized. We have many copies of projects all over different drives and no one can say what is the latest version or what the difference between project "AAAA123" and project "AAA123" is. (yes, they keep tacking more A's to the front to get it to the top of a folder when browsing in explorer.) I couldnt tell you what a project or a file is just by looking at the name of it. In some projects, everything is crosslinked to different folders/projects and it is way out of hand. I could go on all day long describing some of these horrors.

The real problem is, they took a group of engineers and said - you are now part of an eCAE team responsible for testing, simulation, and rapid prototyping (of ECU modules) These engineers (and I use that term loosley) have no software engineering background and too stubborn to admit they dont know the correct way to do something or ask for help. We use many different softwares including Labview. I have the most experience with Labview and my hope is to at least get this portion of my groups responsibilites in order hoping that it will "rub off" into the other areas and software projects. I need to find one little corner to start in and hope it will spread but its like talking to a wall.

Ok, I'm done venting for now.

Yes, that is a tough situation that you are in. As others have said try to get some training for everyone centered around software engineering techniques. Another thing you can do is try to persuade by example. Start implementing changes on the code that you work on. Chances are good that your code will start to improve, have less bugs, be more stable and get completed faster. As others start to see the benefits of doing things differently they may start to adopt the things you are doing. Unfortunately this can be a very slow process but over time it generally works. You do need to present your managers with solid information as to why changes need to be made.

[Daklu]

Check with the local NI sales team. Our local sales group has provided on site "brown bag" lunch lessons designed to help developers get up and running quickly. They might be able to talk about the advantages of source control too.