Just a quickie coding style question :
I realize my Open() function (no matter the context) do too much things
: first open file, check if it’s ok, get the properties, then create
another object from this file (here, a sequence from a midi file) and so
on… Do you think it’s better to separate all the parts in different
functions for a better coding style ? How do you usually manage this ?
f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> objects for max/msp | C, java & python
On 11-Apr-2006, at 11:02, f.e wrote:
> I realize my Open() function (no matter the context) do too much
> things : first open file, check if it’s ok, get the properties,
> then create another object from this file (here, a sequence from a
> midi file) and so on… Do you think it’s better to separate all
> the parts in different functions for a better coding style ? How do
> you usually manage this ? Advices ?
The way I learned to do this at uni and the way these things happen
in the real world are not always the same. What was the same in both:
no single cut-and-dried rule works all the time.
In the real world, there is a tendency to be happy when something
works and then leave it. When you find yourself coming back to code
and you see that a function needs to be divided up into parts,
generally for reusability, then you can divide it up into parts.
What training&experience give you is a sense of when to subdivide a
function before you have to come back to it.
Two rules of thumb, salt to taste but do not give yourself a nervous
breakdown about them:
- If a function is too long to print on a single A4 sheet, it would
probably be more maintainable divided into several functions.
- If you find yourself about to Copy & Paste a chunk of code, it may
be wiser to encapsulate it into a reusable function.
There are exceptions and trade-offs to be made.
I recommended the Bentley _Programming Pearls_ books on another
thread as a readable set of essays for developing good programming
techniques. The concrete examples are a little dated, but the
principles involved are still valid.
Hope this helps,
————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
iCE: Sequencing, Recording & |home | chez nous|
Interface Building for |bei uns | i nostri|
Max/MSP Extremely cool http://www.castine.de
there’s always a trade-off between breaking things up too much and
not breaking them up enough. i once fired a programmer for coding an
entire script in one 2,000+ character line of code (it wasn’t the
i try to break things up within reason – those reasons being, 1) if
someone else needed access to the code, i’d need it to be modular
enough in the right places so I could give them a chunk of it and
have them use it, but not the entire thing, and 2) i need to be able
to look back over the code and understand exactly what the heck it’s
doing, at some uncertain point in the future.
especially reason #2… a very good coder once told me, while i was
trying to make a very efficient program, all squeezed into a few
short lines of code, "it’s much better to write something completely
understandable then completely efficient."
they call it "re-factoring," that continual process of taking huge
chunks of code that have been built up over the lifetime of a project
and breaking them back down into (human) understandable bits.
so i didn’t really give a good answer there.
one method is to think of your code in terms of language structure
(because it IS language, after all). try and break your code up into
arts of speech, like "nouns," "verbs," and maybe even "adjectives."
your "nouns" are data objects, or stages, like "key storage" or
"canvas" and your "verbs" are actions like "open" and "search" that
you perform on nouns. the idea is that you look over your code and
see how much you are mixing up your nouns and verbs and split them out.
so in general, i’d say yes, if your "open" function does a lot more
than just merely "open" a file, it’s going to be confusing to you in
the future when you try and figure out where the rest of that code is
that site in "open". and it also makes your code more reusable when
you break it up into smaller, well-though-out chunks.
As others have said, it’s as much about taste and expediancy as anything else; if it works and you can be confident of understanding the code six months from now then you may not want to lose sleep over it.
The most Javaesque way of slimming down is often to go for more classes rather than more methods, so in your case you could have a MidiFile class that is responsible for sanity checking a MidiFile and extracting its properties, and a sequence class that wraps it:
new Sequence(new MidiFile(new FileInputStream(…
a la the dao of java.io.
Oh, I lay no claim to guru-hood either :)