LabVIEW
Inheriting a codebase - the way forward?
Solved!
- last edited on by
Content Cleaner
@armmic wrote:
Yes, SCC has got to be top of my list. In our R&D department we are using GitLab for firmware source code - I've never used it myself (I've used Tortoise SVN in the past). Any experience of GitLab with LabVIEW? - Pros and Cons etc?
Git is perfectly OK... It has added functionality over SVN, biggest one is that you have full repo access (commit, revert, etc.) even when you're not connected.
You can use TortoiseSVN with Git (Git is a SVN client), if you want a slow transition.
I see Git as a step forward (over SVN). HG\mercurial is completely different, being a non-centralized SCC system. So you'd have only local repo's, and a branch is a copy... Git would also replace this functionality, as it does support local repos. IMHO...
Make sure to mark lv files as binary in Git, or Git will merge on occasion:
Also:
configuring-hg-or-git-to-use-labview-compare-and-labview-merge
tutorial-getting-started-with-git-github-and-tortoise-git
Search LabVIEW like a graph! 
@PaulG. wrote:
Why would I want to inherit someone else's stuff?
Nobody in their right mind wants to, but it's not always optional.
Of course when you all work with the same standards, it doesn't need to be too bad to inherit something.
@Gregory wrote:
Here is an old, but relevant post from Joel on Software:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
I think it's only dangerous if your ego is bigger than your brain. And Joel is making an even more dangerous mistake, and that is to generalize too much.
@Gregory wrote:
@billko wrote:
@Gregory wrote:
Here is an old, but relevant post from Joel on Software:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
I think it's only dangerous if your ego is bigger than your brain. And Joel is making an even more dangerous mistake, and that is to generalize too much.
Well, even if you disagree with the tagline, there are still some great nuggets from that article:
"There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong.The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it."
"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed."
That's pretty much what I meant by "ego bigger than brain". If your brain is sufficiently larger than your ego (which is not as common as you would hope), you can recognize whether or not the code is actually in need of a rewrite. I'm a big fan of "don't fix what's not broke" - but at the same time, you have to realize when something actually is broke(n).
So many times I have said, "Man, that code is ugly and likely full of bugs, but it seems to work and no one's complaining."
@billko wrote:
So many times I have said, "Man, that code is ugly and likely full of bugs, but it seems to work and no one's complaining."
It's even worse when the customer decides the code should be rewritten.
"this code needs to be rewritten, to do exactly what it does now".
That's when the programmer's alarm bells should go off. It makes absolutely no sense to rewrite something that isn't broken. Only logic behind it must be that it is in fact broken.
This problem is harder that it seems at first. Not only do you need to rewrite a completely undocumented program, the program itself isn't a specification at all, since it should in fact be 'improved'. At the grace of the customer, who gets to decide what the improvements are, and what the new bugs are.
Make an estimate for the rewrite, and multiply by 4...
