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.
|