LabVIEW Style Challenge - Error Wires

[PragmaTest]

@SteenSchmidt  a écrit :

Yes, and he would have had exactly the same functionality had he wired the error input, he would just have saved the error bundler after the Close.

And if he hadn't made the code much more complex with a For-loop (why would you send empty strings when your file read failed?), he could have skipped the error structure around it all and just used dataflow with the error wire. His code would have skipped almost instantly with 70% less code and a much simpler diagram. We are different there...

Derrick's code on LinkedIn for reference

---

Around half of participants used a for loop...

So yes I agree we are different.

I accept that, even in my daily work : I don't discuss each small detail, I am open to keep and use code that I would have not done like it is. I focus on big issues, I respect freedom of each developer.

I'm quite sure that a company where each developer have no freedom and is targeted for doing something different than his colleagues falls in high turnover.

I would add this is particularly the case with the younger generation, which have a lot of job opportunities and can't suffer any criticism. They are also particularly sensibles to the tone employed (I confess I'm sensible to this too but not as much as them).

Or at least they are like this in France, I'm not sure for the rest of the world. And no, this is not a classical analysis of a old man over young people : I'm only 40 👴 and I hear more and more business owners reaching the same conclusion.

I'm not sure that endless discussions were the intent of the author here, or if he just wanted screenshots with no discussions at all 🙂

Have a good day

[SteenSchmidt]

---

@PragmaTest wrote: I accept that, even in my daily work : I don't discuss each small detail, I am open to keep and use code that I would have not done like it is. I focus on big issues, I respect freedom of each developer. I'm quite sure that a company where each developer have no freedom and is targeted for doing something different than his colleagues falls in high turnover.

Of course the big issues are more important than the small details. But the big issues are easy, the small details are what can actually move the status quo the most over time. All those small steps to improve will actually matter 1000x a year down the line, when your big applications are maintainable and extendable because they are lean and are outputting the proper errors.

If we extrapolate what you suggest, you should call every function in a sandbox, and treat all data as suspect. Instead, do stuff right from the bottom up, and perhaps one day code will be trustworthy.

We discuss the small details to continuously improve. That's a big retention factor at my company. Nobody here would accept to do something that increases complexity and technical debt, when it's clear that there is a better way. Staying quiet is a false sense of freedom, in that case you miss improving because people around you are afraid of giving feedback if it might be taken as an insult. Be afraid of failure and you miss the opportunity to learn. That will be a lesson some in the younger generation will have to learn the hard way, when the woke and cancel cultures finds their proper balance.

A "challenge" to merely submit images with no discussion would be meaningless.

[Yamaeda]

Done!

[PragmaTest]

---

---

@SteenSchmidt look at that, such a good cleanup !

just kidding 😉

[JÞB]

---

@PragmaTest wrote:

---

---

@SteenSchmidt look at that, such a good cleanup !

just kidding 😉

---

Sébastien,  I've been trying to find a way to respond that is both clear and would not be mistaken for simply flame warring.

That's is difficult considering the defenses you have offered for your coding style practices.   So, I'll just settle for clarity and let you read it however you want and let other readers do the same.

If you ran a bakery that had a counter full of rancid lard, weevils infesting the flour and ants in the sugar your products would be lower in quality than I would choose to purchase.  Moreover; certain regulatory agencies might just have problems with your workplace conditions i.e. any state heath board.

  Accepting substandard code components for your software products will negatively impact the quality of the software you can deliver and the cost of chasing down all those trouble tickets you could avoid by simply rewriting a Power Supply driver. 

Likewise, any approved production workflow that permits "Terminate Execution" on a path to product is inherently flawed.  The production test system should never let terminate execution happen without elevating privileges from Production User to: Maintenance/Supervisor/Responsible Engineer and be outside of a production workflow.  Clearly the production user should have the rights only to "push a button- get a banana."

[PragmaTest]

---

@JÞB  a écrit :

---

@PragmaTest wrote:

---

---

@SteenSchmidt look at that, such a good cleanup !

just kidding 😉

---

Sébastien,  I've been trying to find a way to respond that is both clear and would not be mistaken for simply flame warring.

That's is difficult considering the defenses you have offered for your coding style practices.   So, I'll just settle for clarity and let you read it however you want and let other readers do the same.

If you ran a bakery that had a counter full of rancid lard, weevils infesting the flour and ants in the sugar your products would be lower in quality than I would choose to purchase.  Moreover; certain regulatory agencies might just have problems with your workplace conditions i.e. any state heath board.

  Accepting substandard code components for your software products will negatively impact the quality of the software you can deliver and the cost of chasing down all those trouble tickets you could avoid by simply rewriting a Power Supply driver. 

Likewise, any approved production workflow that permits "Terminate Execution" on a path to product is inherently flawed.  The production test system should never let terminate execution happen without elevating privileges from Production User to: Maintenance/Supervisor/Responsible Engineer and be outside of a production workflow.  Clearly the production user should have the rights only to "push a button- get a banana."

---

I partially agree with you and I thank you for clarifying your position.

By default a member of the Operator group in TestStand can push Terminate.

For testing electronic parts I think it's perfectly ok, since there are a lot of situations for the operator to do so. That's why I check Ignore Runtime Error for cleanup steps.

I don't remember one single TS application where terminate has been disable for an operator but I can understand it's a possible use case.

[JÞB]

Thanks for taking that the way I intended 

"By default a member of the Operator group in TestStand can push Terminate."

I Know,  there are other things that I don't really like about TestStand too.  But,  I have specialized in R&D, Design Verification and Production Testing for longer than the original TS development environment has existed. 😉

[PragmaTest]

---

@JÞB  a écrit :

Thanks for taking that the way I intended 

"By default a member of the Operator group in TestStand can push Terminate."

I Know,  there are other things that I don't really like about TestStand too.  But,  I have specialized in R&D, Design Verification and Production Testing for longer than the original TS development environment has existed. 😉

---

@JÞB

I'm a TestStand lover ❤️

After this whole conversation I see that my "silent cleanups" habit come from TestStand and that I transfer this habit in LV.

[paul_a_cardinale]

Inside the .zip file is "Inject Error and Reason.vi" which is an Express VI that I find handy for inserting meaningful errors.

[paul_a_cardinale]

Here is Jim Kring's code, modified to use my Express VI.

Here is the Express VI configuration: