Seeking advice on how to deal with inherited code

[LVIEWPQ]

---

@JÞB wrote:

With only 6 months of exposure to programming in LabVIEW you have to consider yourself an infant.   TRUST ME I'VE BEEN THERE! and without any mentor to guide the team.  We wound up "potty training " ourselves.  Certainly,  we made mistakes and wound up producing piles of feces!  Eventually, we made enough painful mistakes that our code looked pretty darn good.  It took years and countless man-hours of wasted time.

You need a mentor to show you practical use of the Core Training Material to learn without the pain we endured.  

---

Believe me, some kind of mentor would be wonderful, but realistically, I have to accept I'm on my own and likely to be struggling through this on my own. 

[Yndigegn]

Hi

My first assignment as a freshman working with LabVIEW was in 1995. I was given the task to make a not working test system, work. And the code was pretty incomprehensive. Like the code you showed.

But a closer look at your code tells me that it is code not given proper love. I think it will be much easier to understand if you nurse it a little. The code is probably running. Don't break it. Nowadays it is called Continuous Integration.

So what should you do. Clean it up and compact it. Move terminals around to avoid wire breaks. And make things understandable. As an example this :

Three controls. The first one has no name. The 2'nd one is called CHT on the panel. And the unit is outside the control, contrary to the RPM unit. The 3'rd one is called RAO on the panel. The diagram shows this for these controls :

It would make everything easier to understand if Engine Speed were shown next to the yellow control. And the controls called CHT and RAO are in fact called CHT 2 and RAO 2 on the diagram. I consider such choices the sure way to incomprehensive coding. And there is no consistency in the units placement. 

A diagram should not exceed the display size. That was the rule in early 2000'th. In modern talk it would translate to a diagram size of 1200x800. Or something like that. You can create very complex code within that space. LabVIEW diagrams are three dimensional.

The front panel has the controls intended to be seen. But there are control outside that area. Any such controls should be hidden. Makes front panels nice(r) when printed. And other benefits.  

Labelling constants and wires and comment everything you figure out will really help you. But don't re-code anything unless you are VERY sure you understand what the code does.

Good Luck

[Yamaeda]

That's only 15% as bad as i thought it would be!

Just create subvis and give them good names as you start to understand and analyze the code and you should have a much easier time to read and maintain the code.

I like Subversion with the TortoiseSVN interface as SCC, it's simpler than GIT and a good starting point.

[Frozen]

---

@Yamaeda wrote:

I like Subversion with the TortoiseSVN interface as SCC, it's simpler than GIT and a good starting point.

---

I came from using SVN at a previous company and was dumped into GIT in my current company.

SVN is sooo much simpler to understand and use IMHO.

[rolfk]

---

@Frozen wrote:

---

@Yamaeda wrote:

I like Subversion with the TortoiseSVN interface as SCC, it's simpler than GIT and a good starting point.

---

I came from using SVN at a previous company and was dumped into GIT in my current company.

SVN is sooo much simpler to understand and use IMHO.

---

Can't argument with that. 🙂

And for projects where you do not work with lots of people on the same code, and considering that many of the GIT features don't really work well for binary blob data as LabVIEW VIs are, the additional complexity of GIT is not really warranted with any real benefits in comparison to an SVN version control system.

[JÞB]

---

@rolfk wrote:

---

@Frozen wrote:

---

@Yamaeda wrote:

I like Subversion with the TortoiseSVN interface as SCC, it's simpler than GIT and a good starting point.

---

I came from using SVN at a previous company and was dumped into GIT in my current company.

SVN is sooo much simpler to understand and use IMHO.

---

Can't argument with that. 🙂

And for projects where you do not work with lots of people on the same code, and considering that many of the GIT features don't really work well for binary blob data as LabVIEW VIs are, the additional complexity of GIT is not really warranted with any real benefits in comparison to an SVN version control system.

---

I would also add that the TSVN Toolkit from Viewpoint systems is an excellent tool that brings all of the Repository operations straight into your LabVIEW Project. 

[Jay14159265]

---

@rolfk wrote:
...

---

And for projects where you do not work with lots of people on the same code, and considering that many of the GIT features don't really work well for binary blob data as LabVIEW VIs are, the additional complexity of GIT is not really warranted with any real benefits in comparison to an SVN version control system.

---

Out of curiosity I worked in subversion running on a private server for years then was turned on to GIT after changing jobs, are there now some good options for free hosting sites for subversion repos?

[rolfk]

---

@Jay14159265 wrote:

---

@rolfk wrote:
...

---

And for projects where you do not work with lots of people on the same code, and considering that many of the GIT features don't really work well for binary blob data as LabVIEW VIs are, the additional complexity of GIT is not really warranted with any real benefits in comparison to an SVN version control system.

---

Out of curiosity I worked in subversion running on a private server for years then was turned on to GIT after changing jobs, are there now some good options for free hosting sites for subversion repos?

---

Free not that I'm aware of and even commercial webhosters do not support that out of the box anymore. My internet provider used to have SVN support in the past but they stopped with that several years ago. They also don't support GIT of course. I suppose with enough effort you could get your own things working in that respect with a full SSH access, but I'm not that geeky. Instead I use a Synology NAS and have the SVN server on there.

[Yamaeda]

---

@Jay14159265 wrote:

---

---

Out of curiosity I worked in subversion running on a private server for years then was turned on to GIT after changing jobs, are there now some good options for free hosting sites for subversion repos?

---

I've used ProjectLocker in a previous project, but i not completely free. $19/mo isn't too bad for a basic account though.

ProjectLocker Plans & Pricing

Quick search gave this: RiouxSVN — Free, Private Subversion Hosting

I know nothing about them, but it seems they give out 4x 50MB repo for free, and you can upgrade it with 20MB/dollar and other stuff.

[Bob_Schor]

There actually is a "Free Hosting Site" for Subversion.  Look up VisualSVN, which has a "Free" option.  We've been using the "Enterprise" version at the University of Rochester for (I'm guessing here) 10 years, and it is fairly easy to set up.  The Enterprise version has a cost based on number of users, starting at a shockingly-reasonable price for up to 10 Users.  The "catch" is you have to Host it Yourself (as @rolf has done).

Another relatively-low-cost option for SVN is Assembla, which I've also used, with relative ease.

Bob Schor