address@hidden wrote: I would like to get back on the right
foot with FluidSynth. I find I often feel like I'm neglecting the
project and then try to avoid thinking about it at all, to try and
side step the unpleasant feeling there. My intent is to change this.
After all its a volunteer effort and should be fun to work on! :)
Hi Josh, glad you're back and feeling better. Ironically my ten year
"vacation" from computer obsession involved a lot of drinking and
substance abuse, so now sitting in front of the computer half the day
is comparatively healthy for me. What's interesting is the feeling you
describe having about the project. When I was a teenager I would
literally code so long into the night I had to stop from exhaustion,
only to repeat the procedure again the next afternoon. Back then I
was the old-school definition of a hacker and I just kinda winged it
through complex projects without doing a lot of preparation or
planning. After a few months of this I often would have painted
myself in a corner. The project code would be so immense and
convoluted that I was no longer able to comprehend it as a whole. Any
time I'd try to work on it after that, whether fixing bugs, finishing
features, or adding new features, I would get this odd feeling of
dread. Even thinking about the project while away from the computer
would fill me with that feeling. Ultimately the projects were
abandoned and lost due to hardware failure and insufficient backups
(tears...).
I don't know if your bad feeling is caused by the same reasons as
mine or not, but if so I recommend a few general things that could
help:
* Create a simple but complete document describing the program
flow. Make sure the descriptions in the document actually match the
modules/procedures/functions/whatever in the code, grouping several
together if necessary. I don't know if a full blown flowchart is
necessary, but even a simple linear outline with indentations could
help.
* Decide based on that document whether that is the most logical
way the program should flow. If not, create a draft document by
rearranging and modifying the descriptions in the first document so
the proposed program flow is more logical.
* If the program logic did need to be rearranged, do all the
copying/pasting/modifying necessary to rearrange the actual code and
test it to see if it still works as before.
* Clean up the code (formatting, procedure names, variable names)
and comment it exhaustively so you can read through it faster.
At least in my mind, half of the coding logic's goal is to make it
work and be efficient. The other half is making it sensible to human
readers so it can be easily improved and maintained. My coding skills
these days probably suck compared to yours so my suggestions may
already have been implemented, but hearing about the feeling you were
having worried me because it brought back my own memories of my old
projects and how they ended up.
KEVIN FISHBURNE