common practice for creating utility functions?

[Paul Rubin]

John Salerno <johnjsal at NOSPAMgmail.com> writes:
> So my first question is this: should I make a Cryptogram class for
> this, or are functions fine? If the latter, then back to my original
> point: can I do something like this:
> 
> def convert_quote(quote):
>      return make_code(quote)

It's fine to do that if it expresses your intentions more clearly.
It's also normal to write a call for a function you haven't written
yet:

   some_quote = convert_quote(another_quote)

where you write convert_quote afterwards.  It may not be til you
actually write convert_quote that you notice that it simply calls
another function.  If that happens, it's fine.

Also, you don't need to make a class if you don't need to do OOP-like
things with the instances.  But, sometimes, making a class also
clarifies your intentions.  For example, making a class means it
becomes much simpler to have multiple cryptograms active at the same
time, if you want to do that.

Programming is not just creating strings of instructions for a
computer to execute.  It's also "literary" in that you are trying to
communicate a program structure to other humans reading the code.

Someone once asked the famous bike racing champion Eddy Merckx (he was
sort of the Lance Armstrong of the 1970's and then some) how to become
a good racer.  His answer was "ride a lot".  It's the same way with
coding.  As you get more experienced these questions get easier to
answer for yourself.  But always, do whatever works, and if your code
gets messy or hits technical snags, ask yourself what alternative
approaches avoid those snags, and thereby develop a sense of what to
do.