Since you mentioned "application", I'm going to assume you are running code here which monitors the buttons and contacts. If that is the case I can tell you from my experience that it better to do your de-bouncing programmatically. Consider developing a function that you occasionally call to check for button hits. Without delving into any particular language, what the function would do is this...
- As a one time initialization, set a variable to the value of your systems millisecond timer, and maybe initialize a static 'button variable', as a bitmap of all your buttons, and set it to zero (or "-1" if "HIGH" is the default state of your buttons). Also, initialize two variables, one to represent your debounce time in milliseconds (start with 20, for example).
- When your application calls your function, it should check the button (or multiple buttons). If no button has changed state when compared to your stored variable, just return the existing stored button state variable.
- If any button has changed state, check your current system millisecond timer, subtract the time stored in the timer variable you previously initialized. If the difference is less than your debounce time, just ignore the change and return the unmodified button state variable.
- If you get to this step, then one or more buttons HAS changed state, AND at least your specified debounce time has passed. In this case, store the new button state in your button bitmap, re-initialize the timer to the current system millisecond time, and return the button variable.
Thats all there is too it. You've not only saved yourself at least 2 components per button (the RC network), and have effectively created a "brick wall" filter, much more precise and consistent than the RC network would be. In addition, you have made it very easy to change the all important debounce time without de-soldering parts.
One note on this methodology, it is also possible to call a similar function by interrupt instead of calling it as part of a round-robin sequence in your main program loop. In my opinion this is NOT a good idea, because a defective noisy contact would generate lots of interrupts which could easily bog down your program. Generally in larger systems where an interrupt actually does report button hits (like a keyboard interrupt in a computer), the button hits have already been pre-processed by a small dedicated MCU in the keyboard itself. If you're doing it in a smaller system, and doing ALL the de-bounce yourself, the method I'm suggesting is a better choice.