Bitwise operators are powerful, fast, and direct. They do precisely what they should do.

They're also seen by some misguided souls as an 'elite' way of writing code; a way to tell everyone that the author is an expert in all things programming. This is a common trap to fall into.

Here are my rules for when to use bitwise operators. This is by no means a finished document.

Most importantly: do you, the programmer, understand bitwise operators? If you don't fully understand what you're doing or why you're doing it, you're writing clever code, and you're doomed to debugging hell. If you're copying someone else's code, this is doubly true. Only write what you can understand! This is a universal rule.

Next on the list: Will it make your application noticeably faster? Look at your language, and the position in the code where you want to use bitwise operators. If you're using an interpreted language, is there actually a speed improvement, or would the interpreter already perform the optimization (or perhaps be so slow it doesn't make a difference?) Next, is your code executed often? There's a lot more good that comes from a 100% speedup of an inner loop than a 100% speedup of a block of code executed once.

If you see a noticeable speedup and understand the code you're writing, please use it. Efficiency is always good. Document anything that isn't blindingly obvious. The more speedup this gets you, the more lenient you should be about using complex code - sometimes it's worth it!

Similarly, using bitwise operators may net you little to no speedup, but it may drastically reduce your code size. I see this often in the embedded world. My favorite do-everything 8-pin microcontroller has 64 bytes of RAM; 64B is not a lot of room, and I want to use every single bit of that in a useful way. In ages past, cutting several bits off a program could save the company millions of dollars by letting them use a smaller chip. Today this may still be the case in certain embedded devices (such as toys, where you might find 4-bit and smaller processors, and every penny per tube of 10,000 processors matter), and some of those toys ship in such incredible bulk that it's still cheaper to pay engineers to figure it out. However, to but it bluntly, if you have this sort of size restriction, you know more about bitwise operators than I do, and know dozens of ways to make your code smaller. You're way past this article.

If there is not a noticeable speedup, nor a large reduction in code size, bitwise operators should only be used when they're actually clearer than other code would be. For normal arithmetic, this is rarely the case. For dealing with colors, images, video, audio, and certain math, you will use bitwise operators almost every time. You can expect to see this pop up in almost any security-related operation, such as hashing, encrypting / decrypting, and so on. You will use bitwise operators to access bits and bitranges of memory-mapped registers in the embedded world. You may want to use bitmasks with enums (or maybe magic numbers, sadly) to store the presence or absence of flags in a single flag field. You'll use them all the time with deep debugging (often in the form of hex dumps). If you're dealing with hex dumps in kernel development, what are you even doing reading an introductory article?! Anything related to assembly and computer architecture is nearly impossible without a great understanding of operations on a bit-level. Compression requires working on the bit level. Networking, both from the hardware and software sides, requires this as well (especially when coupled with compression and/or security.) Devices/peripherals and associated drivers will work on a bit level. The list really grows incredibly long, but it's still dwarfed by the day-to-day programming where you shouldn't try to be fancy by replacing a divide-by-two with an arithmetic-shift-left, lest you wake vengeful slumbering gods.

In summary: only when you know what you're doing; and only when you get either a good speed improvement, a good code size improvement, a readability improvement, or when it's the only choice, or some combination of those. Don't be clever, and don't prematurely optimize!

Remember: Code so that the next maintainer (who happens to be a psychopath and knows your address) won't knock on your door. Or, more reasonably, code so that you don't hate yourself in two months.