Unless you’re working under some unique circumstances, endianness is not something you need to deal with often as a programmer. If you think you’re being presented with a unique circumstance, think it through. Maybe you can avoid dealing with it.
Let’s define endianness first. The first thing to realize, and this confuses me all the time, is that this has nothing to do with bits. The smallest element here is the byte, and it will always be in the right direction, even if it’s logically or physically forward or backward or sideways or whatever. You’re not going to write a 1 somewhere and read a 255 back somewhere else, no way, no how. What endianness does have to do with is what order bytes have in a set of bytes. So, say you have a four byte word and you write it to memory address 16. Each memory address represents one byte, so the word is going to exist at memory addresses 16, 17, 18, and 19. By the way, you can remember it’s not 13, 14, 15, 16, because then writing to 0 would land most of the word in a negative memory address. So if the word represents the number 0x02000001, does address 16 get 0x02 and 19 0x01, or does address 16 get 0x01 and 19 0x02? Endianness doesn’t come up frequently for me, so I’ve thought about ways to remember which is which.
Little endian is the “simple” one because the least significant byte (0x01) goes at the smallest address (16). The words “least” and “smallest” go together, and that’s simple, and simple things are little. Simple things don’t need much context to remember.
Big endian is the one, so the most significant byte (0x02) goes at the smallest address (16). Don’t think that big endian has the most significant byte at the largest address; that’s just the other side of little endian. Big endian is like writing a number down in a notebook where the first digit you wrote is in the smallest address. To many people this is the “natural” way to write numbers. But, like many things in life, the natural way and the simple way are at odds. Many of us have a big shared context that is the culture surrounding how you write numbers. So although big endian is complex in that “least” and “smallest” don’t match, it’s embedded in a big context we can usually take for granted that makes it easy to remember.
I’d like to mention that little endian is easier when you’re going from a value to a sequence of bytes. Let’s call this serializing. On the other hand, big endian is easier when you’re deserializing. What I mean by “easier” is that it takes a loop containing a mask and a logical shift. The “harder” side involves a backward loop or a more extensive masking and logical shifting.
The second thing I want to talk about is how to respond when you’re unsure if something you’re using is going to switch endianness on you. At the University of Toronto I was given some code that read and wrote bitmap files, and at the time I thought it was awesome that I got something that could do that. Later, when I needed to deal with bitmaps again, and I wanted a better interface, I delved into the file. What I found was, I’m pretty sure, a huge overreaction to endianness worries. Bitmap files have an endianness to them, so that has to be respected. But the code was written to respond to whether the machine running it was big or little endian. This is stupid! Now, the code was in C++, and I don’t know what happens when you write a four byte word, say, an unsigned integer on today’s computers, to a file. Maybe the ordering is dependent on the machine, maybe it isn’t. So why worry about it? Split everything up into bytes yourself and write those in the order you want. It’s not like anything you do at the logical level is going to be different across computers. Addition works the same on every computer. Division and modulo work the same on every computer. Logical shifts work the same way on every computer (hence logical). The only thing I can think of is that the code was originally written for a system which took significantly long to read and write bitmaps files, and working with multiple bytes at once was faster than a single byte at once.