Enumeration's default value is integer. However, when we use Enumeration we don't use so many values. So my questions are:
enum TYPE : byte{HORIZONTAL , DIAGONAL} //uses 1 byte
enum TYPE {HORIZONTAL , DIAGONAL} // int by default. Uses 4 bytes
P.S I apologize for bad english it is not my native language.
I've never experienced an issue defining Enums with default Integral type, and you seem not to have an issue yourself. If you ever experience a memory issue in your system it is more likely that it is caused by other issues and not by choosing int over byte for your Enums.
Those little micro-Enhancements has rare impact in today's cheap memory computers.
Unless you're working on embedded systems with limited memory, try not to focus on those micro-optimizations.
1) Does 3 byte space save us so much space? How does it effect nowadays computers?
Whether it actually saves space depends on a lot of other things. For example, if you use your enum as a field inside another class, things might (or might not) get memory aligned. I am not sure about the specifics in C# (even in C++ this can be a complex topic) - maybe this SO answer clarifies some things.
Even if it were guaranteed that using a byte enum always saves you three bytes, consider how many enum instances you use in a typical application. Ten? One hundred? Maybe a thousand? We are talking in the order of kilobytes here, while modern computers have at least gigabytes of RAM, that is 6 order of magnitude more.
2) If yes, why its default value isn't byte?
This is a decision by the team that designed C#, we can only assume they had their reasons.
Yes, a byte can only hold values up to 255. Now probably most enumerations don't have more than 255 values, but for example for Flags enums that only gives you 8 possible flags and you may need more. Also, since enums are basically just integer numbers, you want to be able to do integer or bitwise operations on them (like + or |) -- again this is especially true if you have enum Flags -- and those work on full 32- or 64-bit integers anyway. In fact they may even be slower for bytes because the value has to be expanded to a full integer and then truncated again.
3) What should a good programmer do?
As usual, unless you are writing performance or memory critical applications, don't worry about it. Especially in C# with its smart compilers, it is easy to apply premature "optimizations" that actually slow down the performance, so unless you have very convincing evidence that you actually need those three extra bytes, just write the code for legibility and not for speed. Even if the theoretical 3 byte difference actually turns out to be there in practice, you probably lose a multitude of that in other "inefficiencies" such as padded classes, inefficient string operations, copies of local variables, etc.
