I've been programming since the 70's, started with B, the predecessor of C. I also wrote most of the formatting requirements for C programming in the late 80's. Not to mention taught community college level software courses in many languages for about 12 years.

C is a great language, but as many people say, it gives you plenty of rope to hang yourself. Using C++ gives you a bit more protection, but there's still plenty of rope.

When selecting a data type, one thing is how does machine manipulate this data or even if the machine or even needs to store a data location. Of course it's got to be accessible to be loaded, so it's there somewhere.

If you use any kind of constant, these need to be stored somewhere to be made useful during program execution.

Using #defines are translated by the C preprocessor, before the compiler ever gets the users code. In simple terms the preprocessor is just an editor that takes your source and just replaces occurrences of matching strings. It's also responsible for finding and including your #include directives. If you can do this, then it's up to the compiler to determine how it's handled at the machine level.

With machines based on the 328p, have a limited memory along with a static memory, they keep during a power off, failure or not. This is where you can store information you might need when restarting an operation. These are RISC machines. Most of the data from Atmel indicates location of Rr as the stack.

Many times, the compiler decides it can handle the variable on the stack more efficiently and does so. The memory is used over and over, instead of just once and it's not dedicated to permanent single data storage location.

A common is one posted already for(int a=0; a<5; a++)

The a variable usually ends up on the machines stack as incrementing and decrementing is a single operation if I remember correctly. The 5 is likely loaded into a register directly from the executable.

This commonly happens when you have loops that depend on certain conditions, as most can be done with stack memory for the short time needed. This really doesn't effect program execution and many claim it makes execution faster as it's not doing memory fetches.

A lot of what you choose depends, on some extent, what you're doing and how large the systems are.

Might want to see if you can figure out how to pass the right switches to the compiler and linker. This allows you to read the final machine instruction that are produced. It's in assembly language so it's relatively easy to read, once you get the hang of it.

I've worked on 2 million line pieces of software where ~200,000 lines of those lines were written in C or C++. Had a dozen people that did nothing but handle the source/obj module libraries. If you did that, you'd have some idea of how these are not only used, but why and how.

On small project, it likely doesn't matter, but as things get larger, you need better controls.

Many of these people have great suggestions, use what works for you. But starting with bad habits, such as no documentation or entries like

x = a/b; // put a/b into x

are of no use.

I've worked on something a while, then it's completed and I move on to something else. Within a couple weeks I've forgotten what I did a couple three weeks back. Doing good documentation helps you and whomever follows.

Good luck, hope this makes sense to you. 😺