Write tests. You have no functional tests at all for anything, let alone regression tests for the issue you've fixed here
I find automated tests of limited use, and a "regression test" wouldn't have caught that specific issue since it's a timing issue/race condition. Instead, i run a couple of non-critical (private) servers that use Net::Clacks under real life conditions and exercise every part of the protocol. I usually upgrade those servers a few days before a new release to see if everything works as it should.
I'm planning to clean up the code (up to a certain point). But the main function will most likely stay over 500 lines long, simply because it's a state machine and i like to be able to follow all the critical parts of the state flow without jumping in and out of subroutines in when reviewing the code. It's a personal preference thing.
In reply to Re^2: Net::Clacks Important data corruption bugfix released
by cavac
in thread Net::Clacks Important data corruption bugfix released
by cavac
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |