Pete Gonzalez wrote:
>
> Daniel J Sebald wrote:
>
>> Søren Hauberg wrote:
>>
>>> Yeah, the names are probably too general (I believe we have a 'hilbert'
>>> function already that generates a Hilbert matrix). Perhaps
>>> 'hilbert_curve' or the long-and-obvious name
>>> 'hilbert_space_filling_curve'?
>>
>>
>> Long names aren't good. Go for short condensations. Aim for no
>
> > underscores if possible. For example, hilfil.m gets the point
> > across and has an aliteration memory aid.
>
> MATLAB was designed in an era when there were only a few hundred
> identifiers to distinguish. Memorizing that "hilfil" means "hilbert
> space filling curve" was a small price to pay for saving some keystrokes
> on that clunky terminal with no cut+paste.
I say that still holds today. I much prefer things like "cd" as opposed to
"change_directory".
> By contrast, modern namespaces contain hundreds of thousands of names.
> People today spend a lot more time reading code than typing it.
I spend a lot of time typing code. cut+paste are great, for big hunks of code.
But composing code still requires efficiency in keystrokes. As far as reading
code, long function names can send things off the viewing window.
But there is a difference in the setting. If it is production code unique to
some device or program, then long descriptive names are good because it informs
the reader about what this function (one they've never seen) does.
Furthermore, and importantly, there is no help feature to explain what the
function is.
In the case of the hypothetical "hilfil", I discover that by looking at the
package list "fractals" ("miscellaneous" isn't descriptive about category) and
next to the function name is a description of what it is. If one comes across
an unknown function name in some code, he uses the help feature.
There is a place for long function names, but once a function reaches
package-status, or operating-system-status, or programming-language-status,
brevity is good. I'm not strongly against "hilbert_space_filling_curve", but
lean in the direction of shorter is better.
> Most
> programs are too big for any one person to have read every source file.
>
> We can't change the standard function names established by MATLAB, but
> if we define new functions, I don't see what's wrong with intuitive names.
"hilfil" isn't non-intuitive, it's cryptic. But once one knows it (similar to
commands like "freqz") it's easily remembered. The saving grace for
remembering something like "hilbert_space_filling_curve" is tab completion.
Dan
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
