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

colporteur said:

Are there some best practices a novice could use in applying these to get the most benefit from their programming?

Please take this the right way: the best thing you could do is sit down with a book/coding website and learn the basics of C programming.  It may be beneficial to skim C++ because you've probably come across a number of libraries written in this language - but that would be better on a "need to know basis".  I check your programming questions that you raise to see if I can help and will continue to do so, but I think you'd really benefit from investing some time in learning.  Understanding types and how they interact with each other (e.g. type casting) is critical; understanding modifiers such as const, static is also critical.  This doesn't mean you would then not copy-and-paste code but it would really help you understand what others are writing in their code and the bits that are genuinely relevant and/or how you might change it and integrate it better.  And I can promise you WILL become confident how to use them very quickly. Notwithstanding....

int, byte, unsigned integer, .... are what are termed 'types' in a programming language.  They tell the compiler what type of value a variable will contain: e.g an integer cannot be assigned a value of 12.5 (actually, it can but it will be truncated to 12 but you get the point); similarly an unsigned integer variable cannot be assigned a value of -12 (again, it can but it will be some head-scratching value nothing related to the number 12 but calculated from a twos-compliment translation.)  In the cases where you do assign an invalid value you will get a compilation warning so you will know something strange has happened.  I can guarantee you get this: you know that you can assign a number to a number type and a character to a character type right?  You probably don't understand what the difference between int, signed integer, integer, unsigned integer, byte, float, double, long, etc etc... These are selected not just by what sort of number you can assign, e.g. an integer value such as 12 or a float value such as 12.5, but by the size of that number.  If you define a variable as a type of byte then it can only hold a value of 0 - 255 (8 bits) - if you assign it a value of, say, 257, it will just rollover and be set to 1 (0b100000001 - and only the last 8 bits are used) and you'll get a compiler warning.  The problem is that on different architectures, some of these types are different sizes: e.g. on a 16-bit processor int is likely to be 16-bit but on a 32-bit processor it is likely to be 32-bit (i.e. a much bigger number can be stored.)  There is no way around understanding this - you must check it for the processor you work with.  That's why James has mentioned STDINT library and the types defined there such as uint16_t which is guaranteed to be 16-bits irrespective.

I think you're getting the idea that there is no substitute for learning this and whilst it may seem complicated, it really isn't once you set to it 

const is just short for constant by which you promise the compiler you won't change the value post compilation, e.g.

const String grassColour = "Green";
...
grassColour = "Blue";
...

The compiler would throw a wobbly seeing this and refuse point blank to compile.  There are other benefits which new programmers may not pick up on:

const String grassColour = "Green";
....
if (grassColour == "Green") {
  doSomeStuffHere();
} else {
  doSomeCrazyOnDrugsStuffHereInstead();
}
...

The compiler would almost certainly optimise this code to:

const String grassColour = "Green";
....
doSomeStuffHere();
...

Because the code in the else block can never be reached as grassColour is ALWAYS green.  It also does some other optimisation stuff like:

const String grassColour = "Green";
String leafColour = grassColour;
...

Would get optimised to:

const String grassColour = "Green";
String leafColour = "Green";
...

This has memory consumption benefits which is useful to know when developing for memory constrained systems.  Note there are syntactical variations where you define a constant but don't assign it a value at the same time; in this case the compiler will expect you to have initialised it before referring to it elsewhere in the code and then NOT to change it once you've done so.  There are probably edge cases where this is useful and worth understanding but in the majority of cases you would initialise the constant when you define it.

#define is what is called a pre-processor macro (and in no way related to the way I have used "define" in the last sentence in the previous paragraph.)  Before compilation, a pass through the codebase is made dealing with the pre-processor statements.  In the case of #define, it is a substitution macro:

#define grassColour "Green"
....
String leafColour = grassColour;
....

would become, after pre-processing and fed into compilation:

String leafColour = "Green";
... 

Every place in the source code where grassColour was used is replaced with the defined substitution.  Yes, you're right: that is JUST like using a const and is often used instead of creating const variables (an oxymoron if ever there was one) - in modern compilers that you would use there is no cost benefit to using either, and whilst purists might argue the nuances of one vs the other, for your purposes those arguments are irrelevant so pick a style and go with it.

I agree taking the time to learn is ideal. I have to balance that understanding with what I will retain. I will never be a programmer. I cobble together short snippets of code. Curiosity for the most part has me asking questions. 

I appreciate you sharing your insight. Now if I can put it some where so I can recall it would be nice.

Before I retired and when I was interested in furthering my career(s) I struggled with what to learn and what to retain. It seems I learned Pascal, VAX, Basic, Perl, python and xhtml but have retained little, especially in Perl. Coding Arduino's came when I retired. I did a full fledged course on Python during the pandemic and fall short of being able to write code from scratch.

I have coded errors using wrong data types. Those I have managed to figure out. floats and int have caught me lately but I am getting better at identifying when they are needed.

I agree taking the time to learn is ideal. I have to balance that understanding with what I will retain. I will never be a programmer. I cobble together short snippets of code. Curiosity for the most part has me asking questions. 

I appreciate you sharing your insight. Now if I can put it some where so I can recall it would be nice.

Before I retired and when I was interested in furthering my career(s) I struggled with what to learn and what to retain. It seems I learned Pascal, VAX, Basic, Perl, python and xhtml but have retained little, especially in Perl. Coding Arduino's came when I retired. I did a full fledged course on Python during the pandemic and fall short of being able to write code from scratch.

I have coded errors using wrong data types. Those I have managed to figure out. floats and int have caught me lately but I am getting better at identifying when they are needed.

colporteur said:

I have coded errors using wrong data types.

From experience, 3 good ways to learn coding really better:

• join a software developer community. One where code is discussed. Discuss along. Do not ask for coding practices on an electronics forum . (Except if you need an embedded specific advice)
• read a book about professional coding, in the language you want to learn better (e.g.: Industrial Strength C++ by Mats Henricson an Erik Nyquist). 
• read other people's code, love what they do well, and adapt it. 

I have visited that pool and discovered I don't really enjoy swimming there. I wasn't aware of the limitation between coding and electronics in the E14 Community. I assumed it was technology. Arduino technology such as coding was permissible.

I will never get to the level of professional coding. Mine is an interest (they did it because) and not a profession (it is important that do that because). Great resource I will try and use it. I like the reference to style in the appendix. I seem to recall I had a similar reference style-guide for Python in Visual Studio. At least my code looked I knew what I was doing:)

The last bullet point works if you have the knowledge to understand why they did what they did and not why they did something different. This whole thread was sparked from a tech tip I received in an email about using #define.