NI Traffic Light CLD Soln vs mine

[richjoh]

If my memory serves me right, there is no queues discussed in Intermediate I or II. Futhermore, the NI master slave design pattern found in the LV New VI dialog uses notifiers. I did do the code in 60 minutes, the other hours was making sure it worked. guess, I need another hour to add documentation and a 3rd hour to checking for "Style" thats loosely defined per the LV design guide http://www.ni.com/pdf/manuals/321393d.pdf#labview_style_guide.

As far as using quote unquote the good connector pane, i.e. 4x2x2x4, that training rhants about, I prefer not too. Use only the amount of conncectors necessary and yes make terminal required. Try debugging some large application (1000 VIs) that someone inadvertantly connected one of those empty connector panes to the wrong wire or just leaves it unconnected all together.... Apps like this are not for the cookie cutter LV programming "Style" guides...

The comments on my CLD are open to interpretation. According to NI, you should not pass on "Style" alone. your need 30 out of 40 points. Style is 15, Func is 15 and documentation is 10. The fact your passed tell me this was a subjective judgement call.

[Dennis_Knutson]

---

As far as using quote unquote the good connector pane, i.e. 4x2x2x4, that training rhants about, I prefer not too. Use only the amount of conncectors necessary and yes make terminal required. Try debugging some large application (1000 VIs) that someone inadvertantly connected one of those empty connector panes to the wrong wire or just leaves it unconnected all together.... Apps like this are not for the cookie cutter LV programming "Style" guides...

---

I am now in a position where I have to maintain and update a very large application with several hundred VIs and most of those used the absolute minimum connectors (sometimes only 1!). Adding inputs and outputs breaks all of the calling VIs and this is not pleasant to fix. This goes beyond what I would consider a 'style' element. If I could find the amateurs that did the original programming, I would beat them over the head with the nearest heavy object. You can't even connect a wire to an empty connector either so I don't quite understand your comment about that.

I happen to believe that style is incredibly important for the developer when he or she is part of a large project and working as a team. It's next to impossible to manage large projects when everyone is doing things differently. I sympathize that you have taken the test  and haven't passed but use the experience to learn from. I now work for a company that  will pay the exam costs so we will see how I fare.

[waldemar.hersacher]

I passed not only on style but most of the points came from there. From the functional part the initialization and configuration was working. Only after starting the execution part the program didn't work.

[richjoh]

If the prior developer had left you extra connector panes and the run arrow did NOT indicate broken because of some callers and changes you made, well I guess you would find this out at run-time or worse at the customer site.... I'm not the only one using minimal connectors. In fact I always use the minimal, what wrong with adding an addition connector when you need it. With modularized code it should be painless. Nothing wrong with 1 connector if thats all thats required...

[Dennis_Knutson]

I'm becoming less sympathic to you. There is actually quite a bit wrong with not leaving empty connector panes. If you have a subVI that is used in multiple locations, changing the connector pattern will require you to go into each calling VI and re-link the subVI. All of this is unnecessary. As a long-time developer, I realize that functions will change over time and a subVI may require new inputs or outputs. Failing to anticipate this and not making it easier in the future for myself or whoever, is dumb.

[smercurio_fc]

Let me start out by saying I've never taken the CLD, so you can evaluate the validity of my comments based on that. I have been following your comments regarding the CLD and its grading. It seems quite clear that you are quite annoyed over the result of the CLD in your case. My suggestion: get over it. Really. ALL standardized tests are subjective in either their construction or their grading. That's the nature of standardized tests. For some people this works out great, for others, not. Just because it didn't work out so well for you doesn't invalidate the test or its grading.

Your comments seem to be centered on trying to say that "NI doesn't seem to follow its own guidelines". Well, that's hardly a surprise. Have you looked at some of the VIs that NI wrote way back when? I shake my head sometimes. OK. So what? Does this mean that NI trying to put together a set of syle "rules" is hypocritical? Of course not. LabVIEW is a programming language, and just like any programming language you need to have some guidelines on how to program. Frankly, I commend NI for trying to put out a set of guidelines on good programming practices.

For those of us who've been programming for a long time it's obvious that there's no "one style fits all". The point of the CLD, based on what I've seen, is not to say the "one style fits all". It's to say that style matters. And believe me, it does. You can't count the number of times I've reprogrammed something that someone else wrote or that I wrote myself because I didn't think it was "elegant". Did it work? Yes. Was it "sylish"? No. That's why I reprogrammed it. In many ways how you program says more than what you program or how fast you can program. I don't like to be rushed. I like to take my time to consider what I'm doing and evaluate all the possibilities in my head and determine which is the most elegant solution in terms of minimized code and style. Yes, style.

As for the connector pane, not having a connector terminal available and then having to change the connector pane requires you to go into every VI that uses that subVI and relink to that subVI. That's why the use of the 4-2-2-4 pattern was adopted as a conventionally accepted pattern to use. It minimized this happening without creating a connector that required a microscope to connect a wire to.

[richjoh]

I scratching my head, I don't get your connector pane issue. Adding another pane does not break your code. Your existing wired connectors persist. Removing controls or indicators a certain way will add some additional debugging, maybe this is your issue...

I doing whats recommended by NI to take the practice exams but when I look at the work of the example well you be the judge... I don't mind kissing up for the exam.

[richjoh]

----------------------------------------

I'm becoming less sympathic to you. There is actually quite a bit wrong with not leaving empty connector panes. If you have a subVI that is used in multiple locations, changing the connector pattern will require you to go into each calling VI and re-link the subVI. All of this is unnecessary. As a long-time developer, I realize that functions will change over time and a subVI may require new inputs or outputs. Failing to anticipate this and not making it easier in the future for myself or whoever, is dumb.

--------------------------------------------------

Dennis we are in agreement here,

I don't leave empty connectors like you mentioned above. yes forcefully changing panes is a nono, adding a necessary connector is painless. Others obviously consistently use the 16x2x2x16 leaving empty connectors, open for inadvertant connections.

[Norbert_B]

Just to enter discussion here: CLD takes "following the style guide" as a large part for its result. The reason is very good explained by Ed.

The LabVIEW Style Guides, which are "tested" with CLD are subject to change. For instance, a year or two ago, nobody cared about "connector panes". But as Dennis or smercurio already stated, connector panes ARE important and can change; therefore, there should be a "rule" in the guidelines.... viola, here it comes. And 4x2x2x4 was chosen because of wiring errors and references......

So, just to give you a small hint: keep in touch with the up-to-date version of LabVIEW and the current standard of the style guide.

As the name "Style Guide" already implies: it is not a rule you have to follow in your daily work. Maybe, some of the content may be awefull for you; nevertheless, the NI Style Guide was built by experience on HOW TO SOLVE SOMETHING BEST. And regarding that NI examples do not follow the style guides:
a) most examples are older. So there was no style guide to follow or the style guide maybe had some changes in between. NI does not reprogramm all examples just to keep up with the guide just like you wouldn't do it as well i asume....
b) even newer examples break the guide; there are several reasons: esp. size is broken due to architectural reasons... the creator of the example is not aware of the current state of the guide .... we are all just humans 🙂
c) There is no silver bullet in software developement (see http://en.wikipedia.org/wiki/No_Silver_Bullet)

just my subjective thinkings,
Norbert

[altenbach]

---

TonP wrote:
Before you go the XControl way, it is pure overkill.

---

I am not so sure, because making such an xcontrol is very fast and then you only have to deal with three values for each light (red, green, yellow) instead of a set of three booleans that can have 8 different states, 5 of which are illegal! Have you ever seen a light where the red and green are on at the same time? An accidental click in the wrong place could do that in the current code and even Darrens VI analyzer would not complain about it. 🙂

Maybe even faster would be a picture ring containing the three images of the possible light states.

I really think boolean structures are NOT the way to go here. 🙂

The code needs to be designed in a way that is is easily readable and is inherently bug resistant. If I look at all these boolean constants in the posted codes, I cannot immediately tell if everything's OK. Can you?