
Recombine to avoid naming when naming is hard - mightybyte
http://www.lispcast.com/avoid-naming-at-all-costs
======
natch
This article is taking its readers down a really dumb path.

"At all cost" even at the cost of readability?

It also ignores the possibility that good names do exist, and that they
contribute a lot to maintainability.

The suggestion made is when a good name "cannot" be found, you should try to
avoid naming. No. Bad suggestion.

When a good name cannot be found, you probably have muddied up the problem,
and should rethink it. Or try harder to find a good name. Also re-examine your
ideas about what is "good", avoiding false metrics such as "names need to be
under three characters long".

~~~
dasil003
> _When a good name cannot be found, you probably have muddied up the problem,
> and should rethink it._

Absolutely. Software as we know it could not exist without abstration, and
abstraction can not exist without names for things. Sometimes a new name is
required because a particular concept or application is relatively novel, but
if you decline the challenge of naming it then progress stops immediately. No
future applications will be built on top of an unnamed abstraction.

------
nightcracker
Bleh.

I think the software development industry should stop doing such a disservice
to itself, and start funding more scientific studies in software development.

Random, almost shower-thought hypotheses like 'naming things is hard - we
should stop doing it' are given way too much credibility with nothing to back
them up.

~~~
lsc
>I think the software development industry should stop doing such a disservice
to itself, and start funding more scientific studies in software development.

Hm. I wonder if some of the larger companies are doing that sort of thing and
keeping it internal-only or using it for internal coding standards without
publishing it in an attempt to gain competitive advantage?

~~~
bunderbunder
I doubt it. And even if they did, I don't think you should expect their
results to generalize.

There's some evidence to suggest that the reason why studies like this so
often produce seemingly conflicting results is that there aren't very many
universal rules. The same practice can be helpful for one team and harmful for
another based on any number of circumstances.

~~~
tetha
It's even in the same company. My team has very few common problems with our
product teams. In fact, some of our experiences are just contrary to the
product teams experiences.

Overall, software development is looking more and more like a journey to me.
And a journey in the polar sea is different from the journey in the sahara.
Just don't leave jenkins at home in either case.

~~~
lsc
eh, I think that there is a lot of value to standardization. Your average
programmer is gonna spend more time reading code than writing it; there's
something to be said for getting used to one standard style.

------
nine_k
When naming things is hard, it's _exactly the reason_ why you should stop,
think, and find a good, fitting name.

If you have hard time naming something in your code, chances are it's because
you have a nebulous understanding of that elusive thing. This is obviously bug
prone. It's usually a good idea to spend a few minutes searching for a good,
precise, descriptive name, and add enough comments if the entity being named
is not a temporary variable.

Doing so not just makes later code maintenance easier, it tidies up your
understanding and can even lead to finding a bug or another problem (happened
to me more than once).

~~~
tetha
In my team, we're starting to take naming problems as a very, very red flag.
Especially if the name makes sense for half the team, and no sense for the
other half.

In the most extreme case, we've taken like half a day off with the entire team
to discuss just about everything. We went from a name to one of our software
to our architecture to our domain and it was just half a day to a day of
discussion and merging understandings.

After this, we spend another half a day to a day just cleaning up a huge mess
of potential bugs, and after that, naming was simple. And now, a few month
later, hell it was worth it.

------
stephengillie
> Naming is hard because it's a different kind of thinking from the rest of
> programming. We are coding along, in a nice engineering flow, and all of a
> sudden, we need a nice, human-readable name. We need to find compassion for
> the reader from within our cold, calculating programmer trance. This is very
> difficult.

This makes me think of prescription drugs, and how they all have 2 names, one
for marketing to the public, and one for marketing to doctors. [e.g. "Ask your
doctor if Savator is right for you. (Dipromelexeline)"]

------
abrgr
As I read it, this article is, quite intelligently, recommending (or at least
a consequence of their logic would be a recommendation for) using a point-free
style wherever it's applicable. Programming is, primarily, data transform and
a focus on the transform, rather than naming the intermediate data items, is
typically a lot nicer to read. Name your functions, avoid naming your data if
you can.

------
PythonicAlpha
I don't agree.

I agree, that naming is hard, of course.

But I don't agree, that you should avoid it at all costs!

Sometimes, the costs are just to high. When by avoiding naming things, you
make the program more difficult to understand, you loose much. This could cost
you nearly as much, as a bad name and very likely much more than a half-good
name.

------
dang
Threads like this are so sensitive to initial conditions. When one initial
condition is a dumbed-down, provocative title, we nearly always get a dumbed-
down and provoked discussion. That's too bad, because there are some good
ideas here.

We changed the title to a representative sentence from the article.

------
mkozlows
The article is maybe overblown, but I think there's a good point there. A lot
of functionality is one-off stuff that doesn't need to be re-used and won't
be, and so trying to come up with a name for a little chunk of code just ends
up making the program harder to understand.

So, sure, you can write:

    
    
      function processData(err, data) {
        //blah blah does stuff
      }
    
      db.getData(processData);
    

But it's actually a lot simpler and more understandable if you just write:

    
    
      db.getData(function (err, data) { 
        //blah blah does stuff
      });
    

If and when you ever need to break that function out into something re-usable,
give it a name then, but don't bother with a name unless you need it.

~~~
Ma8ee
I hope that the very generic names you have chosen is just for the example,
but otherwise that is exactly the type of names that make a codebase
incomprehensible. How about something like

    
    
      function CalculateSalesBonus(err, salesmenEmployedByTheLastOfMonth) {
      // do stuff
      }
    
    

which actually contains much more information than

    
    
      db.getSalesmenEmployedByTheLastOfMonth(function (err, data) { 
          //blah blah does stuff
      });

------
king_magic
Posts like this give the illusion of saying so much, but at the end of the
day, they really say almost nothing at all. What actionable advice is this
post really giving? What examples is it pointing to to illustrate the author's
point?

    
    
      > Use threading. Instead of naming each intermediate value, thread the value through the process without naming it.
    

What does that even mean?

To be honest, I'm not even really sure what the author's point is. Naming is
hard? Naming is bad? Don't name things? Name everything? It just feels like an
abstract nonsense piece.

~~~
mbrock
Threading aka chaining aka composing. You describe a pipeline and then send a
whole value through it, thus avoiding the naming of intermediate results.
Functional programmers call it "point-free style." It can't save you from
naming in general, since each piece of your pipeline will be named, but it
saves you from naming "variables."

Here is an example of the main part of a Haskell program (using the "pipes"
combinators). It starts two concurrent pipelines. One reads user commands from
a queue, encodes them, then writes them to an AMQP server. The other reads
results from the AMQP server and runs them through a more complicated
pipeline, the details of which aren't very interesting.

    
    
        runEffectsConcurrently
           (contents commandQueue >-> encoder >-> writeTo amqp)
           (readFrom amqp >-> decoder
                          >-> skipEmpty
                          >-> logToFile
                          >-> forever (decodeMsg state)
                          >-> toChannel eventQueue)
    

What I like about this style has to do with how it avoids naming intermediate
results. Instead of stuff like loops, anonymous callback functions, and
variables, it approaches a declarative specification of the program's
structure & behavior. I still had to give names to each component, but I
didn't need to come up with names for the values that flow through the
pipelines.

~~~
king_magic
Yeah, that makes sense. The author's terminology/wording wasn't clear/helpful
IMO.

Beyond that, though - the above code looks great - until you need to debug it.

Personally, I'd rather pay a 'naming tax' on things for the sake of
readability / debugability over what the original author is shooting for any
day.

~~~
mbrock
I haven't needed to debug it very much. Thankfully, it's easy to insert
debugging helpers at any stage of the pipeline.

~~~
king_magic
Interesting, maybe I'm just less familiar with debugging in Haskell.

~~~
mbrock
This is kind of a special scenario since what's described in the pipeline is
already an I/O action, which makes it easy to insert logging anywhere (e.g., a
"tap" component that prints its input and output w/ timestamp).

Such pipelines aren't necessarily made up of I/O actions though; they can also
be pure computations, which cannot perform side-effects such as logging. In
that case, you can still insert debugging helpers, but you might need to be
slightly creative. For example, if your pipeline generates a list of values,
you could put debugging entries into that list.

Generally, though, the saving grace in such a case is that each component will
be a pure transformation, which means that you can easily call it with a test
input and inspect the output.

There are some step-by-step debugging tools for Haskell, but I haven't used
them, and Haskell programmers mostly seem uninterested in that way of
debugging. It doesn't fit very well with Haskell's evaluation model anyway.
When I work with Haskell, I just debug in a different way, focusing on
verifying correctness of functions and their combinations.

~~~
codygman
> There are some step-by-step debugging tools for Haskell, but I haven't used
> them, and Haskell programmers mostly seem uninterested in that way of
> debugging. It doesn't fit very well with Haskell's evaluation model anyway.
> When I work with Haskell, I just debug in a different way, focusing on
> verifying correctness of functions and their combinations.

I created hs-scrape[0] to write web scrapers and I frequently use the ghci
debugger[1] for step-by-step debugging.

0: [https://github.com/codygman/hs-scrape/](https://github.com/codygman/hs-
scrape/)

1:
[https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci-
debugger.html)

------
AnimalMuppet
There are times to break some code out into a separate function, even though
the function will only be called in one place, _simply because the name of the
function will make it more clear what the code is doing_.

Note well: This is not "always". Do not do this with every single line of your
program. This is not even "often". But once in a while, it can dramatically
improve clarity.

------
andallas
I see this same issue come up from time to time and I always recall a little
saying I heard (unfortunately I don't remember the source).

"If you are having trouble naming something, then you don't fully understand
that something."

What I get from that saying is that if I have a function that I am struggling
to name, it means that I don't fully understand the problem, and there's a
good chance that it is doing to many things. Keep your functions to performing
a single task, so they have just that one purpose, then name it after what it
does. This improves readability and makes naming things much easier.

You have a variable you can't name, well, what data is it actually holding? If
it is holding more than one piece of data (reused) then you are doing
something wrong or very hacky.

Follow the same rule as with functions. Keep your variables to holding just
one specific piece of data, and name it after that.

Both of these rules not only make naming things much easier, I've found they
produce much more readable code, easier to debug code, and generally much less
bugs in the code.

------
PaulHoule
Yeah, I have been looking at why production rules systems (OPS5, Drools, IBM
ILOG, etc.) have not caught on and I think one of the problems is that most of
these systems make you give every rule a name, which is like saying every line
of source code has to have a name.

~~~
frobaldo
I've spent half a year of my professional life programming custom business
rule engine and my experience aligns with a sarcastic note I've read
somewhere: "Business builds business rule engines so they can change their
rules and workflows without the need for expensive programmers, but in the end
they need to hire even more expensive Business Rule Engine Programmers".

Declarativeness of the system was really nice and named rules really made
sense, if the actions you can take are really meaningful. It was more like
naming every function set while doing FP.

~~~
braythwayt
I call this "Duck Programming:"

[https://unspace.ca/dev/2012/duck-
programming](https://unspace.ca/dev/2012/duck-programming)

------
a3n
Good idea, _sometimes_.

On the opposite end, I will sometimes go out of my way to name something when
there isn't an immediately apparent need.

Also naming can often shorten up a long line.

Trivial example:

    
    
      In [15]: SortByLen = lambda x: len(x)
      
      In [16]: SortByLast = lambda x: x[-1]
      
      In [17]: listOfInterest = ['123', '234', '432''12', '12345', '123']
      
      In [18]: sorted(listOfInterest, key=SortByLen)
      Out[18]: ['123', '234', '123', '43212', '12345']
      
      In [19]: sorted(listOfInterest, key=SortByLast)
      Out[19]: ['43212', '123', '123', '234', '12345']

------
ggchappell
There are some good thoughts here, but it isn't all quite coherent yet. So, to
add my 2 cents:

There are basically two reasons to name things.

1\. Because something is lacking in either the syntax of our PL or our skill
in coding, so that we end up giving something a name, when it does not really
need one.

2\. As a handle on some abstraction, indicating what it is for.

When #1 is the issue, names are best avoided. When #2 is the issue, names are
a Good Thing, but a poorly chosen name can be very harmful.

------
harel
Ignoring the fact I think this is bad advice, I actually find 'naming' things
to be good fun. I enjoy finding names for projects. Sometimes I won't write
the first line of code until I either find a permanent name for the project or
a good enough temporary one to name the code directory. Can't reason this
really, but its definitely important to me to know I'm working on a named
project.

------
gweinberg
Sounds like terrible advice to me. Names make it a lot easier to keep track of
things. Even a meaningless name is generally better than no name.

------
haberman
The Phil Karlton quote is fun and clever. But people should not mistake it for
actual wisdom.

Read this paper (for example) and tell me that naming and cache invalidation
are harder than that: [http://www.sigops.org/sosp/sosp09/papers/klein-
sosp09.pdf](http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf)

~~~
AdrianRossouw
i prefer the varian't that says :

There are only 2 hard problems in programming:

1\. naming things.

2\. cache invalidation.

3\. off by one errors.

------
Ma8ee
I agree with those that thinks this is horrible advise. If the function of
what you are naming isn't clear and precise it is of course hard to give it a
clear and precise name. But the solution isn't to avoid giving name. The
solution is to make sure that function of what you are naming is clear and
precise. That is the hard part, but must not be avoided.

------
vmorgulis
It is similar to sociology or psychology problems.

They use models or paradigms with lot of names mainly because of lack of
theory than can connect human sciences to mathematics or physics. In each
model they can solve some aspects but the whole.

It looks like zoology or biology before DNA.

------
CmdrKrool
This sounds like the currently fashionable argument to avoid comments because
they can be inaccurate, go out of date, and after all the code itself should
be self-explanatory - just shifted a bit further up the chain.

------
k__
FP isn't a golden bullet, but at least it often helps to get rid of those
temporary variable names that clutter the code.

------
castratikron
Juliet said it best; What's in a name? That which we call a rose by any other
name would smell as sweet.

------
anton_gogolev
> There are two hard things in computer science: cache invalidation, naming
> things, and off-by-one errors.

