Jump to content

How NOT to code large applications


Recommended Posts

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:

post-37-1121272432.jpg?width=400

Link to comment
  • Replies 56
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment

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. :blink:

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"

Link to comment
  • 1 month later...
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.

Link to comment
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 :(

Link to comment

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

Link to comment
  • 3 weeks later...

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

Link to comment

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...

Link to comment

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

Link to comment
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.

:yes: 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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.