Re: Reading Someone's Program

[Tux]

• Reformat/reflow to your liking. Preferably with Perl::Tidy, so the new layout is both documented and reproducible.
• Do not rewrite function-based code to OO-based code just because it is more modern. There may be (very) good reasons other than modernizing the code, but simply because you think OO is more modern or because you like OO is a very bad reason for such a conversion. To me that sounds like implementing threads in a program that doesn't gain anything by that.
• Add comments! Everywhere that you needed time to investigate, add comments.
• Start writing tests based on the docs and based on any fix you make.
• Replace local option parsing functions with Getopt::Long and write a good usage function.
• Create a two-sided TODO list. On the left "Have to change", on the right "would love to change". Postpone the right until everything works and you have spare time.
• Use a good VCS, like git and commit often with very clear commit messages.

[Anonymous Monk]

A good rule of thumb for the "often" part of local committing is:
you've changed something and managed to get it to compile again -> commit!

[Voronich]

"managed to get it to compile again" o.O? I'm going to assume you mean "have added thorough tests for the changed code and confirmed they all pass".

[Tux]

No, that would be the commit following :)

I really don't like having the (small) fix in the same commit as the commit that adds a number of tests to verify the fix. Note that the OP is dealing with a project that does not have tests (yet).

In a project where you do test-driven development, I would completely agree with you.