[spion]

> Marriages of what? Sam and Bob? George and Shirley? Second the expression itself. Again what is a bob and jane? What is a partner? Partners in crime? Also seriously:

And we get to the key point you are missing. Its clear from the context. The code we had wasn't some imaginary code where the variable was far away and had a ton of context. It was that particular code. Different code might be better written in a different way. If you a have different code context in mind with higher complexity, show that one.

Additionally, "merge_married_profiles_into_list_of_pairs" is not necessarily better. When debugging the code, we don't know what that part really does. An implementation using a more generic standard library function lets us glance over that bit since we already have understanding of it. (And again, it might depend on the audience - are we talking to a language expert, or a domain expert? Do we have a well tested and well defined library of domain functions that everyone has a clear understanding of?)

Context and audience matter. Verbosity can be a lazy cop out for bad structure. (That's applicable to writing English as well.)

[Geminidog]

>And we get to the key point you are missing. Its clear from the context.

I understood this point utterly and completely you have misunderstood the point I was making. I am saying you can't rely on context because context can grow in complexity and can actually live far away from where you are using a variable or a function. Relying on context leads to code that will inevitably become less and less readable as complexity grows. Read my post. I literally addressed "context" and you literally missed my point.

Let me spell it out for you. If I have a 500 line piece of code, Bobs is created on line 1 then reused again on line 500, and I'm currently looking at line 500, you're expecting the reader to scroll all the way back to line 1 to decipher context. Couple that with multitudes of other concepts littered throughout your code with context strung throughout the page and located in different files.... This is my point that I demonstrated to you earlier to COUNTER your point. Once you realize this, you'll know that you're the one who missed the point.

You function name should be so clear that a reader should never have to read context. He reads the name and he can move on with life without decoding everything you did.

If I called the variable list_of_profiles_named_bob, no context is needed. Critical information lives and moves with the concept.

Let me reiterate my point: Context used in place of naming is done by programmers who are bad at writing readable code.

>Additionally, "merge_married_profiles_into_list_of_pairs" is not necessarily better. When debugging the code, we don't know what that part really does.

This is 100% better. Nobody needs to know what a function actually does, this is how abstraction works the point is that you only need to dive in when there is bug, but before there's a bug complexity should be abstracted away so we can make sense of the bigger picture.

>And again, it might depend on the audience - are we talking to a language expert, or a domain expert? Do we have a well tested and well defined library of domain functions that everyone has a clear understanding of?

I assume the audience can understand english. No need to use "inner join" when both the person who knows SQL also knows english. I chose the methodology that everyone can understand. What is the cost of doing this? Nothing. Just a longer function name that actually does zero harm to the structure of a program.

>Context and audience matter.

Audience matters, assume the audience can read English and generally program, that's it. Context as a communication medium is a crutch used by bad programmers to avoid abstracting concepts and giving things clear names.

> Verbosity can be a lazy cop out for bad structure.

Verbosity and naming have nothing to do with structure this is categorically wrong, and also obvious but whatever, I'll show you..

   func add_two_nums(x,y):
        return x + y

   func add(x, y):
        return x + y

Literally, 2 functions that do the exact same thing. You may claim the bottom function is better because it's shorter. And I claim it's shorter by a measly two words, who cares, both functions convey equal meaning and equal structure.

>are we talking to a language expert, or a domain expert?

Literally domain expert code is a synonym for bad code. All code that is bad, when studied long enough will produce a domain expert that knows that shitty code inside and out. A domain expert is someone who mastered (or wrote) code only readable by other masters of reading that same bad code. Think about it this way, if you posted your code on github and people started reading the code, all domain expert code will be regarded as shitty code. This is the colloquial definition of bad code. The best code is code on github that should be readable by non-domain experts on a single pass.

Now I admit that there are some cases where it's just too hard to do this. You can't program a simulation in relativity that's so readable that someone who doesn't understand relativity can read the code. Of course that's just too much to ask. What I'm saying is that "inner_join" is utterly unnecessary and that "merge_married_profiles_into_list_of_pairs" way better then what you came up with.