[Top][All Lists]

[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

    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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]