How NOT to code large applications

[JackHamilton]

Eventually,

You'll get to the point of being asked to fix some existing LabVIEW code. Although this is not the worse I've seen, the sheer size of the block diagram is spectcular!

Even on my wide-screen laptop 17" it still is several screen wide.

Notice the liberal use of local variables! :headbang:

[Ed Dickens]

I refactored an application about a year ago that was originally written in LabVIEW 4 and had been slowly added to over it's 7 year life. Needless to say it was a monster. It's only good point was that there were decent comments on the diagram.

It scrolled up/down about 5 screens and left/right about 3 on a 1280x1024 monitor. Not a single control or indicator was wired to anything. All data was passed through either local or global variables. There was almost 250 local variables and about a dozen globals with several controls on each. There were nested sequence structurs, a couple 5 structures deep.

I'll see if I still have the original and post a screen shot.

Ed

[Barrie]

Notice the liberal use of local variables! :headbang:

5323[/snapback]

I can't decide whether to laugh or cry.

Thanks for the diversion!

Barrie

[FLX]

Now I know what the navigation window is good for.

But I am sorry for all that people who have to deal with such VIs

[Jack Kelledes]

Good Grief!

Now I don't feel so bad about some of my early projects.

[maximus]

It looks like a C-programmer tries LabVIEW

[i2dx]

It looks like a C-programmer tries LabVIEW 

5357[/snapback]

100% ACK!

i see code like this every day, when i work 4 my keyaccount ...

that's the moment when i say: new or nothing!

;-)

cb

[JackHamilton]

The problem with this situation when asked to fix or enhance code like is this analogy:

You're handed a bizarre birthday cake, it was made by someone who doesn't know how to bake. You don't know if they followed the recipe, or used all the ingredients; more than called for or extra ingredients. They quite possible could have throw the frosting ingredients with the batter and bake it all together. You don't know what temp or how long they baked it.

But! Your asked to make another one! :headbang:

I also tell mechanical savvy clients "Working on code like this is like trying to overhaul a car engine that has been welded together"

[Ed Dickens]

"Working on code like this is like trying to overhaul a car engine that has been welded together"

You're not going to charge royalties for using that line are you? :thumbup:

[badwolf]

Almost all the physicists write the code like this, real Labview programmers (of course) do it better!

[jpdrolet]

I am a physicist.

.

.

.

.

.

.

I'm glad you said "Almost"

[pandaman]

Ha. You can truly tell if a c/c++ programmer changes to LabVIEW when they still put // in their comment boxes...

I still do it even though I know it's redundant

[Albert-Jan Brouwer]

Almost all the physicists write the code like this, real Labview programmers (of course) do it better!

5706[/snapback]

Hey, as a physicist I find that rather offense. Yes, maybe

there often are physics students that can hardly program and

then start to use LabVIEW, with predictible results.

But there is an opposite dynamic: phycisists quite frequently

have extensive programming experience, e.g. with

numerical codes, and end up being more or less obliged

to use LabVIEW to automate some experiment, on account

of LabVIEW's superior support for instrumentation.

In other fields there isn't quite as much insentive for

experienced programmers to switch to LabVIEW because

G isn't that special as a language. The scheduling is a little

odd, but the syntactic elements are nearly the same as for,

say, C or Fortran.

[pandaman]

Hey, as a physicist I find that rather offense. Yes, maybe

there often are physics students that can hardly program and

then start to use LabVIEW, with predictible results.

But there is an opposite dynamic: phycisists quite frequently

have extensive programming experience, e.g. with

numerical codes, and end up being more or less obliged

to use LabVIEW to automate some experiment, on account

of LabVIEW's superior support for instrumentation.

In other fields there isn't quite as much insentive for

experienced programmers to switch to LabVIEW because

G isn't that special as a language. The scheduling is a little

odd, but the syntactic elements are nearly the same as for,

say, C or Fortran.

5717[/snapback]

Tru dat :thumbup: even though I'm not a physicist

[Jim Kring]

Physicists use G force! :laugh:

[Phillip Brooks]

Could just as easily been titled "How to eliminate vendors based on drivers.

[jpdrolet]

Could just as easily been titled "How to eliminate vendors based on drivers.

5824[/snapback]

What a nice if...elseif structure...

I bet it has been coded by a C programmer that didn't know about the switch statement...

[AnalogKid2DigitalMan]

It's kinda hypnotic, sort of when you look at a refection between two almost parallel mirrors.

[PJM_labview]

Could just as easily been titled "How to eliminate vendors based on drivers.

5824[/snapback]

I am feeling dizzy just looking at it!

PJM

[Wolfram]

Could just as easily been titled "How to eliminate vendors based on drivers.

5824[/snapback]

This is the new G-tunnel programming technique.

[Louis Manfredi]

Wasn't there a time long, long ago when LabView case structures could only have two cases, TRUE and FALSE, or am I remembering an early version of some other language?

(I know I once had no choice but to write a program which nested like that, but I can't remember if it was Version 2.x LabView or some early text language.)

A(Edit: Of course in this example, and for all I know for the dimly remembered example in my own past, might be just as well off to index an array as to build the nested case structure.)

Louis

[badwolf]

Hi all!

It looks like that I started a discussion in a discussion. I don' t want to be offensive or not pollute with anybody. Let me be more precise. In my esperience I saw many many students in physics and post doc fellow coding really bad Labview code (something wrong and not working :headbang: ) in order to perform complicated data acquisition. Something would be just enough to educate by explaining them what a state machine is and force them to build subVi with specific functions (and why not....reusable by others!!)

Compliments to forum authors and maintainers

Bye Bye

[Mike Ashe]

This is a great diversion for a few minutes at lunch. I really wish I had kept a scrap library of code like these examples over the years, both diagrams and front panels. However...

I remember one that was for a small measurement tester for hard drive heads that was chartreuse green and magenta ... which my boss and I started dissecting as we were evaluating taking the rescue (excuse me, "refactoring") job. We were laughing until we noticed that the senior engineer in the back of the crowd was turning bright red, ... it was his code and we were humiliating him in front of his peers.

I vowed then never again to criticize code like that in public unless the person who wrote it was there and had told us to pull no punches. Good grief, I'd hate to have to critique the first couple of VIs/project that I did.

Still, the scrap library would be funny for private laughs...

[JackHamilton]

I agree and do not critize code, and believe me I see lots of LabVIEW code. I say any code that works is beautiful.

I do take the gloves off when the client is in the difficult situation of think a 'few minor tweeks' are all that is needed to add: User log-in, data basing, etc.

After a few years and a more than a few projects consuming 2x the time I quoted to 'refactor' the code - I'm pretty candid about the situation of a bad code platform.

Of course the last person to touch the code 'own's it' so this is another reason for being open about the situation and biting the bullet about doing a ground up recode.

Regards

Jack Hamilton

[aledain]

Of course the last person to touch the code 'own's it' so this is another reason for being open about the situation and biting the bullet about doing a ground up recode.

Ownership of the problem. Hmmm. Do you reckon this is unique to the software world? Perhaps its a 'fundamental' aspect of our development world.

I always use the examples of telling the car mechanic to fix my flat tyre after he services my car. Similarly the builder extending my house doesn't believe the death of my wife's plants is his problem either. Another good one is the washing machine mechanic not getting my whites 'white and brighter' after a repair! :laugh:

Imagine if other service industries 'owned' problems! When I use these examples, clients seem to appreciate why software I 'patched' at their request doesn't seem to work quite right anymore.

cheers, Alex.