LabVIEW Style Challenge - Error Wires

[AristosQueue]

---

@Juan89 wrote:

My answer too.

 

---

I like this code, but I think it dodges the point of the exercise. 

This contrived example only makes sense as a style test if it is a placeholder for more real-world parallel programming where you really do have refnum and error wires weaving like a maypole, so I stuck with a layout that achieves that parallelism. 

This solution puts the file reads, the enqueues, and the event generations running serially instead of parallel. Enable iteration parallelism on that For Loop and I'd accept it as an answer, even though you'd still be serializing the Close of the config file. 

[JÞB]

---

@AristosQueue wrote:

 

---

Well, since I see your post here I'll ask the two questions that I'm really no sure of.

1) what catastrophe can occur to cause an error in Get ini Key Value.vi (String) poly

2) What style guide are you applying to Terminal Names?  Specifically why does only one terminal have a Leading Capital Letter?  🤔 (Title Case is my personal preference but, consistency is nice)

[AristosQueue]

2) all the terminals have all lower case. What am I missing?

1) No idea. That wasn’t the point of this challenge. I’m assuming that this is meant to be representative of situations where we do need the error info from all parts and so nice linear style gets tossed. 

[JÞB]

---

@AristosQueue wrote:

2) all the terminals have all lower case. What am I missing?

1) No idea. That wasn’t the point of this challenge. I’m assuming that this is meant to be representative of situations where we do need the error info from all parts and so nice linear style gets tossed. 

---

2) My old eyes misread

 one terminal as "Queue"

1) I kinda figured you could remember if an error was possible in that case.  I was curious enough to ask but not curious enough to dug back down through an API I trust %98.  (Sometimes I really do want a linefeed between sections and can't trust the API to leave them alone.)

[McQuillan]

Hello everyone,

I've just read through all 144 comments on this thread! Thank you all for your input. It has been a very interesting read. 

Reading through the comments has helped challenge my own mindset to be a much more deliberate developer. [I'm intentionally not giving much away - but it has for sure impacted the GDevCon presentation, and how I will broch certain programming decisions]

A couple of notes:

• [In case it wasn't obvious] The challenge template wasn't lifted from a project. We simply chose a well known API and two methods of transport to see how developers would tackle that sort of VI (both in terms of style and functionality).
• Hunter and I originally wrote some requirements to go along with the challenge, but chose not to post them as we didn't want to restrict what you all submitted, and the conversations that followed. I'm glad we didn't, as it allowed us to see the types of assumptions made.
  • With requirements, there would have been functionally correct and incorrect submissions, and the conversation would have been restricted.

[raphschru]

A bit late, but here is my contribution:

Assuming:

 - Queue and Event refnums must be valid, throw an error otherwise;

 - Do not send values for missing keys.

Coding style pet peeves for error handling:

 - Wiring: keep error clusters as horizontal as possible and limit bends (unless a bend allows to simplify several other wires in the diagram), also push them behind all other wire types.

 - Terminal naming: "error in" / "error out". Because the standard "error in (no error)" is too long.

 - (Almost) never use an error structure that encloses the whole subVI, because native LV functions do not execute in case of incoming error anyway. In my opinion this adds noise to the block diagrams.

 - Do not aggressively parallelize code for quick functions (like here "Generate User Event" and "Enqueue Element"). The whole application may have hundreds of tasks runnning in parallel already, and doing this certainly wouldn't make any difference. This also adds noise to the diagram.

Regards,

Raphaël.

[hunter_jki]

Tom and I used many of the ideas from this thread in our Extreme LabVIEW Style Showdown at GDevCon 2023 in Glasgow. Thank you for everyone who weighed in, some of your ideas were great, some were ok and some of you are just wrong, but that's ok. We wanted to have a fun and interesting discussion and this community delivered. Feel free to post your rebuttals 🙂

 

https://www.youtube.com/watch?v=VUACQwXTXzk&list=PLUQdW1SDWK3nTwHwKbCBM9ytlRaMrj3WG

Hunter Smith - JKI