of course, for "home projects" any debounce will work, the simple "read/wait 10ms/read again" - if both reads are same it is "proper" value .. for production - one has to raise the bar ..
My first attempt at asm switch debounce coding did involve a state change latch and also incorporated a cumulative sampling of the switch bounce.
The algorithm required that the switch accumulate a 35 count (at 1 ms per count) 'closed' total before deciding on a keypress. Every time the bounce occurred the cumulative count was reduced by 1. The converse applied to a switch release.
This would result in the software 'judging' the switch condition based on it's behaviour.
The useful part of this is that if a switch bounced for 100ms or more the algorithm would perceive this thru the cumulative counting. It's possible that a switch can bounce so much the cumulative count would take quite long to achieve the '35', but always accurately determine the switch state. The cost was about 100 asm commands for 2 switches. About 50 cmds per switch.
Mike K8LH, however, pointed out that the approach, while valid, required significant processor cycles and use of several persistent GPR variables. Since then I have adopted his parallel bitwise approach to debouncing.
I now use a derivative of his core code to have simultaneous PORT wide (8 bits/switches) debounce AND to determine the following switch states. Cost= 35 asm commands for 8 switches. Abt 4.5 cmds /switch, a lot more efficient than the 50 cmds/switch.
1) Switch Press (short)
2) Switch press (long)
3) Switch press (short) and Release
4) switch press (long) and Release
5) Switch not pressed.
Thus I can have a full featured hierarchical PIC programme menu system with just 2 tactile switches given the 5 switch states mentioned.