Re: naming functions [was: Ibuffer: w and B default to buffer at current line]

[John Wiegley]

>>>>> Drew Adams <address@hidden> writes:

> Is `forward-char' a bad name, because with a negative prefix arg it moves
> backward? Is it a bad name because it is singular and a prefix arg > 1 moves
> further than one position?

> Should the name have been `move-char' or `move-chars'? If so, then what
> about binding forward and backward default behaviors to different keys,
> `C-f' and `C-b'?

> I think (hope) you get the point. A function name only goes so far toward
> indicating what the function does. If a prefix arg to a command chooses
> alternative behavior, then it would often be cumbersome and _less_ clear to
> users, to use a name that tries to summarize all of the behaviors.

The only point I'm seeing here is that we've been imprecise with our function
names in the past. That is not a valid argument for how we should assess
patches in the future.

Yes, `forward-char' is misleading. `move-point' might have been a better
choice. But there are many ships like this that left the port long ago. I'm
not even suggesting we retroactively fix any of them. What I will do, however,
is reject the belief that because it happened in the past, this makes it OK to
extend existing functions like this for the sake of expediency.

So unless you're actually arguing for it to be OK to extend functions beyond
their stated semantics, I hope we can agree on the essential point here: don't
pollute the behavior of functions because it's easy to do so. With just a bit
of extra work, we can avoid unnecessarily increasing our technical debt.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

signature.asc
Description: PGP signature