LabVIEW
Company Views on LabVIEW
I agree with Mark in that every attempt should be made to spend the time to think out a good construct, rather than just jumping in and hacking. As I mentioned, developing some templates for the various vi styles, i.e. "Action Engines", "queued state machines", sub-vi with error handling, and having templated comments in the VI documentation portion can save time as well as make commenting your code easier. Hacking make get something up and running quickly, but if it acts flaky, or you need to add that feature in a month, it very well can take up any supposed time savings. Good programming style takes time to develop, but as you do it more often it will actually become faster, and you will find yourself doing some of the programming "house-keeping" like straightening wires, alining controls and indicators, etc., subconciously while in a "no-op loop" thinking about other aspects of your program. Of course NI has given us better and better tools in the form of "cleanup diagram", etc. (although I just did it on one of my vi's I'm working on, didn't like its idea of cleaned up!). But neatness does count, makes it a lot easier to understand the code, for you or someone else that has to follow you.
Good luck in your attempts at changing the culture at your workplace, and have fun "wiring"
Mark Yedinak wrote:Well, I'll jump in a bit from the opposite point of view.
Opposite of what? I think the original query was on how the OP should approach the situation that he's in. He's a new member of a team. He sees a bunch of spaghetti code, but he doesn't want to overstep his rung for fear he may get pushed completely off the ladder. Sometimes real life forces into situations where you have no choice: get it done, or lose the project, or your job because you're seen as someone who doesn't get things done in time. I don't think anybody here was advocating hack code as being the norm. Just speaking for myself, I know that even in cases where I'm in a time crunch I will "hack" code only as a last resort for the very reasons you've stated. However, reality is what it is. Sometimes you don't have a choice, and there have been cases like this in the past for me, and there will be in the future. I still try to go back and "unhack" the code.
I and others have noted that his best approach is to strike a balance:
don't come off as appearing like a "know-it-all", but still provide
suggestions on how to improve things little by little. As he start
walking up the ladder he will have more clout, and be able to provide
bigger and bigger suggestions. Now, it's quite possible that the group
and/or his manager is looking for a messiah, but I wouldn't bet on it. 
I'd like to offer the idea that a quick "hack" can be a thing of beauty instead of something to be ashamed of. It takes discipline, but if you'll get in the habit of using a template every time you begin to throw something together you'll have something that will serve your immediate need as well as something that can be extended if the quick-fix becomes the basis for the final product. This is especially important because, when programming without time to do the up-front design work, you're bound to miss requirements (because they're often discovered on-the-fly). It's nice to be able to add these features without resorting to the bad programming practices that we bash in other threads.
If it be possible, as much as lieth in you, write clean code. It costs less in the long run.
