When to use int, const int, const byte and Define

Personally, I used to only use #define for text-replacement. So, things like #define NOT_PRESSED 0x1, and #define PRESSED 0x0 for buttons. It makes if-statements more readable. For example, (if digitalRead(pin) == NOT_PRESSED.) Good solution for people who mistakenly think that pull-ups make the inputs inverted.

In the past, I would always define things like pin functions as a const. But lately, I've been using #defines more. For any value that will fit into an 8-bit number, there is no performance difference between a #define macro or a const (of an 8-bit variable type.) For a const that fits into a register, most compilers won't bother treating it as a variable anyway.

As usual, it is more important to be consistent in your code than get worked up over which is better.

Regarding int versus byte, versus, whatever, except for byte and char, I have stopped using types like int. Instead, I use fixed-width integer types like uint8_t or uint32_t or int8_t. These are all part of stdint.h.

Using fixed width removes the ambiguity of "How big is this variable on this processor with this compiler on this week of the year?"

I did a review of your material at the link for De-Bounce. I had read that #define is a text-based symbol substitution. I receive a tech tip in an email that suggested using it to #define MY_LED 13. This is what led to my confusion.

int ledpin = 13;

const byte ledpin = 13;

and now

#define led_pin 13

What is a ressurectionist suppose to believe.

int ledpin = 13; // The compiler will reserve 16-bits (assuming 16-bit processor) at an address in memory to store the number 13 0b0000000000001101.  that address will be used to retrieve the literal when used, every time, because the compiler has no knowledge if that value will change.

const byte ledpin = 13; // the compiler (if it is half decent) will almost certainly substitute the use of variable ledpin with an 8-bit literal value 0b00001101.

#define led_pin 13; // the pre-processor will text substitute, in source non-permanently, the word "led_pin" with the text "13" and then send the source to the compiler.  The compiler will then treat it as a literal integer (so like the const definition) but whether that would be as a 16-bit literal or an 8-bit literal would need to be researched because I don't actually know (it's an interesting thought actually and my first suspicion is that it would choose the most optimum bit size, 8 in this case!)

Any of these work but a ressurectionist will always struggle because they look radically different.  However, this stuff is as basic to programming as understanding Ohms law in electronics.  I'm an (ex-)developer, albeit one who hasn't had a professional development role for over 20 years, who had zero knowledge of C when I picked up an Arduino, so I actually spent some time understanding how the language dealt with types, working out the differences between const and #define, what happens if types are mixed in an expression (e.g int aVar = 12 / 7.1; ) and so on.  These things are so fundamental that even a resurrectionist should take the time to understand it if they intend to spend any time with microprocessors, including Arduino, because copy-and-paste will very often introduce strange errors into existing code (as, I think, you have found out on many occasions.)  I say this in the nicest possible way and not to criticise at all - I honestly believe it will increase your enjoyment of working with Arduinos if you understand a little more than you currently do.  It really will be worth the effort and we can help you clarify points of understanding.  

I still have a problem with C in that it would appear that many 'experienced' C programmers seem to go out of their way to write C code in as an obscure a manner as possible!  I also struggle with pointers despite reading umpteen articles about them and I have to revisit constantly.  

int ledpin = 13; // The compiler will reserve 16-bits (assuming 16-bit processor) at an address in memory to store the number 13 0b0000000000001101.  that address will be used to retrieve the literal when used, every time, because the compiler has no knowledge if that value will change.

const byte ledpin = 13; // the compiler (if it is half decent) will almost certainly substitute the use of variable ledpin with an 8-bit literal value 0b00001101.

#define led_pin 13; // the pre-processor will text substitute, in source non-permanently, the word "led_pin" with the text "13" and then send the source to the compiler.  The compiler will then treat it as a literal integer (so like the const definition) but whether that would be as a 16-bit literal or an 8-bit literal would need to be researched because I don't actually know (it's an interesting thought actually and my first suspicion is that it would choose the most optimum bit size, 8 in this case!)

Any of these work but a ressurectionist will always struggle because they look radically different.  However, this stuff is as basic to programming as understanding Ohms law in electronics.  I'm an (ex-)developer, albeit one who hasn't had a professional development role for over 20 years, who had zero knowledge of C when I picked up an Arduino, so I actually spent some time understanding how the language dealt with types, working out the differences between const and #define, what happens if types are mixed in an expression (e.g int aVar = 12 / 7.1; ) and so on.  These things are so fundamental that even a resurrectionist should take the time to understand it if they intend to spend any time with microprocessors, including Arduino, because copy-and-paste will very often introduce strange errors into existing code (as, I think, you have found out on many occasions.)  I say this in the nicest possible way and not to criticise at all - I honestly believe it will increase your enjoyment of working with Arduinos if you understand a little more than you currently do.  It really will be worth the effort and we can help you clarify points of understanding.  

I still have a problem with C in that it would appear that many 'experienced' C programmers seem to go out of their way to write C code in as an obscure a manner as possible!  I also struggle with pointers despite reading umpteen articles about them and I have to revisit constantly.