[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Re: Fwd: Considering adding a "dispatch" function for compile-t
From: |
Jordi Gutiérrez Hermoso |
Subject: |
Re: Fwd: Re: Fwd: Considering adding a "dispatch" function for compile-time polymorphism |
Date: |
Fri, 15 Aug 2014 09:51:14 -0400 |
On Fri, 2014-08-15 at 05:16 -0600, David Spies wrote:
> 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.
Other people have to read your code. It's not for you right now. It's
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.
It really is not worth arguing over function names, just change them.
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.
> 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).
It's possible to see those past editions by doing
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
usual
hg diff -r --hidden $rev1 $rev2
> 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.
This seems problematic. Already, so soon into development, we're
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.
- Jordi G. H.