Rube Goldberg Code

[PaulG.]

---

@Anthony_de_Vries wrote:

... I think that readability is of paramount importance in code.  The type caste is very clever, but also difficult to understand ... 

---

"Clever" solutions are fine if they are documented. Just a comment or two would suffice.

[altenbach]

Well, at least we got a nice discussion going, which is always a non-negative thing (like the absolute value of a complex number). 😄

[tst]

---

@JÞB wrote:

What Comment do you want?  The labels (and a  remembrance that Greek philosophers have historically run naked in the streets) really hit the mark here.

---

The reason I would want a simple comment here* is twofold: safety (e.g. this could be moved somewhere else and lose its labels, or someone might fail to realize what clever algorithm I'm using even if I think it's obvious) and expediency - I'd much rather read a comment or a function name telling me what a piece of code does than try to read the code itself.

* "here" is a generic term referring to any non-obvious piece of code.

[altenbach]

The right way would be to wrap it into a (possibly unlined) subvi with defined and documented behavior. Suddenly the actual algorithm is irrelevant. 🙂

[JÞB]

---

@altenbach wrote:

Well, at least we got a nice discussion going, which is always a non-negative thing (like the absolute value of a complex number). 😄

---

Well, its not Zero so, it looks like you've gotten a Real Positive output from a complex propsal.  (Should I be embarassed for that pun?)

Spoiler

I will be if the response is.  "Absolutely!"  <Groan>

[altenbach]

I am positive that the distance can be zero. 🙂

[bsvare]

All this discussion really boils down to Self-Documenting code.

Good communication is part of programming. If you don't know how to communicate well, you're not a good programmer. I do agree though that documentation styles where you're required to list all the arguments and what they are is a bad idea; in my experience, good comments tend to be plain paragraphs of text describing what the function does and how to use and what sort of assumptions it makes that you need to be wary of.

[JÞB]

The distance could be zero.  The discussion is demonstrably non-zero. 

Spoiler

Edge cases are like pronouns... Both can screw up a pun!  Read "The discussion" for "its"

[JÞB]

---

@Darin.K wrote:

And keep in mind that tst's version and the OP's version are NOT functionally equivalent.  There are two very common mistakes which could be at play here:  it is very common to over-specify code, and also very common to replace code by incorrect or unchecked assumptions about the input.

Only the OP knows the real intentions, but it is important to consider that perhaps the OP really wanted only the first two elements, and also that perhaps the OP was being too-specific in the code.

And yes I have 99 uses for Type Cast but this ain't one.  (2D is way too restrictive, most of my Euclidean distances are in 100's of dimensions).

This is also why I have TD clusters to represent 2D and 3D points when I really want 2D or 3D points.  If a user is TypeCasting or squeezing or otherwise shoe-horning something into the input, inside my functions I at least have control over what makes it in.  This puts a finite bound on my input validation, often meaning I require no input validation.

---

Yeah, well not all of us need to consider weekly convergent theorems.  (Thank god- my brain would explode!)

[altenbach]

Ouch! (seen here) (Seen here) (EDIT: corrected link to source)