Article - The Importance of Style in LabVIEW Programming

[BobHamburger]

The latest rants on My Blog.

[LAVA 1.0 Content]

Nice posting Bob.

I must heartedly agree. Style without substance...

[TobyD]

QUOTE (BobHamburger @ Jul 10 2008, 08:37 PM)

The latest rants on http://labviewinsights.blogspot.com/2008/07/importance-of-style-in-labview.html' rel='nofollow' target="_blank">My Blog.

Nice tie-in back to the flower at the end :thumbup: .

I agree that the project architecture is important, but that can also be made to stink by ugly code. You said you would "rather deal with a well structured application that happens to have crooked wires and overlapping block diagram objects, than a lovely piece of code that's written without attention to the disciplines mentioned (in your article)." I would agree with that only to a certain point. I think both style and architecture play a critical role in any LabVIEW application. If either one of them strays too far from the path of best practices, the code becomes unsupportable.

[Phillip Brooks]

QUOTE (LV_FPGA_SE @ Jul 11 2008, 10:58 AM)

I must heartedly agree. Style without substance...

I can't write it in Thai, but it goes something like this: Pak-chi roi nah

It means "sprinkle cilantro on its face" (basically cover up the problem)

I think it will take a LOT of pak-chi to cover up the "putrid rotting cadaver" smell ( of the flower; I can't speak for the LV code mentioned )

I would compare some of the code I've seen more to http://en.wikipedia.org/wiki/Durian' rel='nofollow' target="_blank">durian. It smells, is thorny (can even cut you), but contains something good inside IF you can ever get past the smell.

Nice posts Bob, keep them coming...

[JiMM]

QUOTE (Phillip Brooks @ Jul 11 2008, 11:37 AM)

I would compare some of the code I've seen more to http://en.wikipedia.org/wiki/Durian' rel='nofollow' target="_blank">durian

How could anyone possibly voluntarily eat something with an odor that one might consider comparing to pig excrement OR turpentine?!?!

I am in the process of rebuilding an application that was developed using NONE of the considerations of the style guidelines. It had a stacked sequence with 173 frames, many of which had similar disasters inside of them, For Loops with hidden conditional terminals, etc . Yesterday I finished turning one of the frames into a sequenceless sub-vi. when I finished, I felt like I had just taken a shower. It just made me feel clean! :thumbup: Next will be correcting the architecture, which also stinks.

[TobyD]

QUOTE (JiMM @ Jul 11 2008, 09:01 AM)

How could anyone possibly voluntarily eat something with an odor that one might consider comparing to pig excrement OR turpentine?!?!

I couldn't agree more. I work with a lot of Vietnamese people who are always bringing me wonderful things to taste. Most of them are delicious, but I have not yet found the goodness inside a durian. Even when it's in my mouth all I can "taste" is the nasty smell.

[JiMM]

You are a better man than I :worship:

I also work with a lot of people from Asia, but I absolutely refused to let that stuff any closer to me than barely within whiffing distance!

[Jim Kring]

I have a buddy who picked up a box of durian hard candy that he picked up while traveling in the Philippines. He likes to bring the box out at parties and offers them to unsuspecting party-goers. It tastes OK at first, and then, as the candy starts to dissolve, so does the smile on the face of the victim.

[Francois Normandin]

I have a colleague who immigrated from Singapore... he played that exact same trick on our group at the first presentation he gave us. Let's call it a weird "collective" experience!

[Phillip Brooks]

QUOTE (JiMM @ Jul 11 2008, 12:01 PM)

when I finished, I felt like I had just taken a shower. It just made me feel clean!

[Omar Mussa]

Personally, I am not sure I am in your camp on this one. I'd rather inherit code that I can understand quickly and easily that doesn't quite work right, then code that works well that I can't comprehend. Maybe its because I assume that I have the technical abilities to sort out the issues of code that is well written but not functional. I find that code that is not well written tends to become un-maintainable really quickly, and IMO un-maintainable code is basically dead code that will end up getting re-written in the long run or just dropped altogether because nobody can figure out how to use it. I've had countless projects where I've been forced to 'figure out' the intent of the original developer that used bad style and then refactor the code into a maintainable form. I don't know that I've ever had a project that followed all of the coding style guidelines that I had to get 'working'. In my reality, there are few times when you find really clean code that isn't also really well designed code.

I would like to quote Jim Kring on this:

QUOTE

Your code looks great, but less of it would look even better

Also, many of the style guides -- good documentation, etc. are essentially there for (at least) two reasons: 1) to make it easy for others to understand your code 2) to force you into a workflow that compels you to write higher quality code.

I think one of the key issues that is implied here is that style and architecture are somehow seperable. I don't find that this is the case very often. I think that if you are going to follow best practices and have good style, etc. you will generally be compelled to choose an architecture that is scalable and maintainable and write better code as a result.

[Val Brown]

QUOTE (Omar Mussa @ Jul 11 2008, 05:15 PM)

Personally, I am not sure I am in your camp on this one. I'd rather inherit code that I can understand quickly and easily that doesn't quite work right, then code that works well that I can't comprehend. Maybe its because I assume that I have the technical abilities to sort out the issues of code that is well written but not functional. I find that code that is not well written tends to become un-maintainable really quickly, and IMO un-maintainable code is basically dead code that will end up getting re-written in the long run or just dropped altogether because nobody can figure out how to use it. I've had countless projects where I've been forced to 'figure out' the intent of the original developer that used bad style and then refactor the code into a maintainable form. I don't know that I've ever had a project that followed all of the coding style guidelines that I had to get 'working'. In my reality, there are few times when you find really clean code that isn't also really well designed code.

I would like to quote Jim Kring on this:

Also, many of the style guides -- good documentation, etc. are essentially there for (at least) two reasons: 1) to make it easy for others to understand your code 2) to force you into a workflow that compels you to write higher quality code.

I think one of the key issues that is implied here is that style and architecture are somehow seperable. I don't find that this is the case very often. I think that if you are going to follow best practices and have good style, etc. you will generally be compelled to choose an architecture that is scalable and maintainable and write better code as a result.

But don't forget, there can be situations in which BAD code (re: style) is actually GOOD. This can be esp the case given a one person shop, with a proprietary algorithm that needs to be obscured precisely so that others can reverse engineer it.

Bad style in other situation can be precisely what is needed in other situations.

[Omar Mussa]

QUOTE (Val Brown @ Jul 11 2008, 06:24 PM)

But don't forget, there can be situations in which BAD code (re: style) is actually GOOD.

I don't think code obfuscation is the same as 'BAD' code and is not what the article or my post were trying to talk about. The code I'm talking about is the code that anyone who is a professional LabVIEW developer has seen about N times and that many non-professional LabVIEW developers end up encountering too, which is code that is poorly written and poorly documented and on top of that does not follow the LabVIEW style guides in any way so you end up spending time trying to figure out what the developer is trying to do.

[JiMM]

QUOTE (Val Brown @ Jul 11 2008, 09:24 PM)

This can be esp the case given a one person shop, with a proprietary algorithm that needs to be obscured precisely so that others can reverse engineer it.

Why would delivering an exe or password protecting the BD not accomplish this need?

[Omar Mussa]

QUOTE (JiMM @ Jul 12 2008, 08:29 AM)

Why would delivering an exe or password protecting the BD not accomplish this need?

1) Delivering an exe is not always possible (you could be delivering an instrument driver for example).

2) Password protection works as long as you trust that nobody has hacked the LabVIEW password protection scheme. Jim Kring wrote an excellent article http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' rel='nofollow' target="_blank">here.

[Michael Aivaliotis]

In my opinion the code has to be clean and self explanatory. It's not enough that it works or that it has a great design. If it takes me just as long to refactor code as it takes to understand it then I always opt for a refactoring. At the end of the day, I will have become an expert in your code after the refactor, plus it will be easier to understand for then next person.

[JiMM]

QUOTE (Omar Mussa @ Jul 12 2008, 01:06 PM)

1) Delivering an exe is not always possible (you could be delivering an instrument driver for example).

2) Password protection works as long as you trust that nobody has hacked the LabVIEW password protection scheme. Jim Kring wrote an excellent article http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' rel='nofollow' target="_blank">here.

Good points Omar. Having done all of my work for my employer has kept me from having to think in the terms that an independant contractor has to.

[Val Brown]

QUOTE (Omar Mussa @ Jul 12 2008, 10:06 AM)

1) Delivering an exe is not always possible (you could be delivering an instrument driver for example).

2) Password protection works as long as you trust that nobody has hacked the LabVIEW password protection scheme. Jim Kring wrote an excellent article http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' rel='nofollow' target="_blank">here.

Precisely.

Moreover, the point I'm making here is that saying code is BAD implies a perspective from which BAD emerges. The implied perspective of most on this forum -- and reasonably so! -- is for ease of maintenance, ESP for someone else coming along and/or following up. And, in general, that's a very good and useful perspective. However, it seems to me that there are exceptions to this rule just as there are to virtually every other rule.

Having BAD code that is "poorly" documented, intricate, obscure style, etc, etc is actually a very effective strategy TO hide its functionality and this, in turn, makes it much more difficult to hack.

Mike your comment about "if it takes a long time to understand it then I'll start over" is directly germane here. I actually WANT it to take a long time (perhaps an infinite amount of time) for someone who comes along to understand my code, in the specific case of my particular application. Were I writing code FOR OTHERS then it would be a totally different issue and, in that case, I would agree with most of the other comments here concerning style and architecture.

[JDave]

QUOTE (Val Brown @ Jul 12 2008, 02:40 PM)

Having BAD code that is "poorly" documented, intricate, obscure style, etc, etc is actually a very effective strategy TO hide its functionality and this, in turn, makes it much more difficult to hack.

That would be an interesting design review.

"No, no, no. This code makes too much sense! I understand everything you are doing and your architecture is well laid out !! What am I paying you for? Now get back there and obfuscate."

[crelf]

QUOTE (Val Brown @ Jul 12 2008, 05:40 PM)

I actually WANT it to take a long time (perhaps an infinite amount of time) for someone who comes along to understand my code, in the specific case of my particular application.

Unless something untoward happens to you and someone else needs to take over (either with your direction, or in your absence). There are more efficient and secure ways to protect your IP - especially if you want your ideas to continue to benefit the world in your absence.

[Val Brown]

QUOTE (crelf @ Jul 12 2008, 03:25 PM)

Unless something untoward happens to you and someone else needs to take over (either with your direction, or in your absence). There are more efficient and secure ways to protect your IP - especially if you want your ideas to continue to benefit the world in your absence.

<and>

That would be an interesting design review.

"No, no, no. This code makes too much sense! I understand everything you are doing and your architecture is well laid out !! What am I paying you for? Now get back there and obfuscate."

There is documentation and various backups of all of my code -- all in separate China locations -- but all of the pieces needed to understand the code are functionally separated into "objects" -- like good OO architecture... ;-)

If you have them ALL in the "same room" then it becomes far more "doable" for someone else to maintain/extend the current code base.

In re: to your second point above, YES, of course, IF I were programming for someone else, on their nickel, or as part of a team, as I said above, most of what is being said here about style and architecture makes sense and I would agree with it.

My point is solely that there may really be some occasions -- exceptional though they are -- that actually benefit from as much obfuscation being applied, in as many ways as possible, so as to protect IP or trade secrets REGARDLESS of whatever protections are in place. Practices that make the code clearly understandable and easily maintained by ANYONE actually make it that much easier for someone else to hack. And this is esp true if you keep in mind the cautions JKI raised re: placing too much trust in NI's password protection, etc.

[Eugen Graf]

Bla-Bla-Bla

[crelf]

QUOTE (Eugen Graf @ Jul 12 2008, 07:25 PM)

Bla-Bla-Bla

Please give us some context on that almost-statement - at least an emoticon.

[Jim Kring]

QUOTE (Eugen Graf @ Jul 12 2008, 04:25 PM)

Bla-Bla-Bla

QUOTE (crelf @ Jul 12 2008, 05:15 PM)

Please give us some context on that almost-statement - at least an emoticon.

How about an emotional song?

"Fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa-fa... I keep singing them sad sad songs... sad songs are all I know."

[BobHamburger]

It warms the cockles of my heart to see such enthusiastic and varied responses to this topic. However, I feel compelled to elaborate and add to the chatter.

QUOTE (Omar Mussa @ Jul 11 2008, 08:15 PM)

I think one of the key issues that is implied here is that style and architecture are somehow separable. I don't find that this is the case very often. I think that if you are going to follow best practices and have good style, etc. you will generally be compelled to choose an architecture that is scalable and maintainable and write better code as a result.

I disagree. Style is a necessary component of structure, but it is not sufficient. I have seen too many cases where style was great but architecture was completely lacking. I am working on code right now that is well documented, flows properly left to right and top to bottom, has a consistent icon/connector layout, etc., etc., etc. However, the application is lacking a lot of the attributes I associate with scalable, maintainable code. It has no kind of heirarchical abstraction of lower-level details; VIs are vertically integrated to include everything from bit-twiddling to GUI updates. VIs have tight coupling and poor cohesion, and there's no rhyme or reason for what's inside a given VI or what is does. I have no problems understanding what the code does, but it's almost impossible to modify anything without having a dozen unintended consequences of any change.

QUOTE

...various comments regarding obfuscation of details as a means to protect IP...

I simply do not understand this perspective. It seems to me that we are developing LV code in one or more of the following contexts:

1. You're an integrator/contractor, so your customer is paying you to develop code. Therefore, either they own the IP outright, or at a very minimum that have an irrovocable right in perpetuity to use the code without further fees or royalties, depending on the contractual details of the engagement. From both a business and ethical perspective, they have every right and expectation that the code you deliver will be crystal clear to them and conforming to the highest standards of which you're capable.

2. You are developing code for internal use by your employer. In this case there are no IP protection issues, and you have an obligation to your peers and employer to ensure that your code is understandable and maintainable, as crelf pointed out.

3. You are developing code to be sold as a toolkit or library. Legally this is virtually the same situation as (1), except perhaps that you can charge deployment fees for each installation. Since your customers will be incorporating your toolkits into their applications, they have a compelling need to be able to validate the correct operation of their code. You in turn have an obligation to make the operation of your utilities visible to them, so that they can perform whatever QA or validation is necessary.

4. You are developing finished applications which are sold as products. In this case, you compile your code and deliver installers and executables, the same way every other software manufacturer does. Your trade secrets are bound inside your .exe's.

If you are truly producing unique IP that is worthy of protection, then there are only two legitamate business methods to accomplish this. Either you have your customers execute the appropriate confidentiality agreement, or you patent your work. 99 times out of 100, what most people think is brilliant and original work product ends up being knowledge that was already available in the public domain.

QUOTE ( @ Jul 12 2008, 07:08 PM)

There is documentation and various backups of all of my code -- all in separate China locations -- but all of the pieces needed to understand the code are functionally separated into "objects" -- like good OO architecture... ;-)

If you have them ALL in the "same room" then it becomes far more "doable" for someone else to maintain/extend the current code base.

Maybe I'm completely misunderstanding your intent in these statements, but it sounds like you want your code incomprehensible as a means to prevent your customers from using other resources, so they are compelled to keep coming back to you. Personally, I think that the quality of a contractor's work should stand on its own. Customers should be so delighted that further engagements happen as the natural course of the business relationship. If I found out that one of my contractors was deliberately engineering complexity into their products, to try to ensure repeat business, I'd see to it that they never worked for me again.

Intentionally making your code obscure, as a means to protect what you believe to be unique, is legally unjustifiable and morally indefensible.