I often myself creating functions which perform a rather clear and
simple task, but which is hard to describe, either because I don't
know the term for what I've just implemented, or because the function
is difficult to summarise in a couple of words. As an example, I've
just created a function which determines how many times the value n,
can be divided by the base, until n becomes smaller than the base.
Here's the implementation...
(defn <insert-name-here> [n base]
(loop [n n count 0]
(if (< n base)
{:val n :count count}
(recur (float (/ n base)) (inc count)))))
This can be used among other things, to determine how to format bytes.
Say I have a file that's 6,789,354 bytes, and I want to display that
in a more readable manner, I could use my unnamed function like so
(<unnamed> 6789354 1024), and get a new appropriately rounded number,
including the number of times it has been rounded, which I can use the
pick the appropriate suffix from a list ("Bytes", "KB", "MB", "GB",
"TB).
I mean, what the hell would you name this function, or would you not
create such an obscure and generalised function to start with?
On Feb 4, 3:15 pm, Jonathan Smith <jonathansmith...@gmail.com> wrote:
> A function would be named based on what it is that it does.
>
> Difficulty naming functions would imply to me that the functions
> involved do not contain a clear functionality.
>
> The names of the functions should sort of be an 'emergent property' of
> a larger process of reasoning through the programming problem.
>
> As I see it, there are two ways to do this...
> The first (systematic):
>
> 1.) break the program into reasonable steps
> (a concise description of the step being the function name)
> 2.) make a function for each step.
> 3.) break each function into steps
> 4.) goto 2 until you are able to describe different pieces of the
> program in the base language.
>
> the second (haphazard):
> 1.) start writing code into a function (name of overall functionality)
> 2.) when the code gets to a certain size, decide that you have too
> much code in the function.
> 3.) look for different pieces of the task that you could potentially
> pull out and name, or patterns that repeat more than once.
> 4.) pull them out and use them as functions.
> 5.) loop through this process of expanding the code and rewriting it
> until you are done.
>
> I could write these as functions
>
> (defn systematic [idea]
> (let [sub-ideas (partition-idea idea)]
> (map #(unless (atomic? %1) (systematic %1)) sub-ideas))
>
> (defn haphazard [functionality]
> (let [[refactored-functionality & new-functions] (extract-
> functionality functionality)]
> (map #(unless (atomic? %1) (haphazard %1)) new-functions)))
>
> Ideally these functions lead to the same output.
> In my use of map I am assuming a lazy programmer without a deadline.
> In the case of a motivated programmer, we might use dolist.
> In the case of a lazy programmer with a deadline, we might use doall
> or dorun..
>
> >On Feb 3, 10:47 pm, Wardrop <t...@tomwardrop.com> wrote:
> > I've always struggled when it comes to defining good names for
> > functions and methods. Now that I'm learning Clojure, function naming
> > becomes even more imperative, as you don't have classes and objects to
> > help give meaning to a method. I'm finding at the moment that I'm
> > spending half my time thinking of decent names for functions. I'm just
> > wondering what process you all use when it comes to naming functions?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
