|Subject:||Re: Fwd: Re: Fwd: Considering adding a "dispatch" function for compile-time polymorphism|
|Date:||Fri, 15 Aug 2014 11:31:23 -0600|
On Fri, 2014-08-15 at 05:16 -0600, David Spies wrote:Other people have to read your code. It's not for you right now. It's
> It's true I feel somewhat like my code is being over-scrutinized. In
> particular, I don't see the purpose of nitpicking over the names of
> "private" functions that aren't intended for external use.
not for the computer (the computer is just as happy with unreadable
assembler). It's for us. We have to be able to understand 10 years
from now when we read this what was going on in your mind. This
includes your future self.
There has to be a better name than "find_to_R". Just "find" would
be better. Most functions do something and store the result in some
object, but they are not all named VERB_to_OBJECT and naming
something that way does not help with understanding.
There already is a "find".
With the same signature?
It really is not worth arguing over function names, just change them.
Names like dir_to_template don't tell me much. The purpose of this function is what? [continues on to guess correctly what the function does, but does not suggest a better name in that case]aren't much help in that department because I don't know what constitutes "better" if I'm not already on the same boat philosophically
There is, sort of, an existing Octave style. Stick to it. Such
bikeshedding battles are not worth fighting. When I contribute to any
project, including Octave, I follow the existing style. Each project
has its own style and the people in it have a particular idea of some
basic idioms of how things ought to be done.
It's possible to see those past editions by doing
> However I have made quite a few changes in response to John's
> reviews. As a rule of thumb, anything I don't protest or just
> respond with an "Okay" is a change I made (it may be hard to tell
> from the revision history sometimes since I use hg amend to fix it
> because all this code is so far back).
hg log -r --hidden 'allprecursors($revision)'
where $revision is the revision whose past editions you want to study.
If you want to see the differences between any two of them, do as
hg diff -r --hidden $rev1 $rev2
This seems problematic. Already, so soon into development, we're
> However, it's hard to make major interface changes at this point
> (such as embedding the direction in the iterator type itself rather
> than making it a template parameter of the step function) because
> all the rest of the code I've written for this project relies on the
> interface as it is now.
locked into a particular way of doing things, a way that can't be
changed easily? The whole point of this summer project was to change
how things were done.
|[Prev in Thread]||Current Thread||[Next in Thread]|