Because register reads can have side effects, they're not pure like reading RAM. Reading a peripheral's data register (e.g., a UART receive register) frequently clears the associated "data ready"/RXNE flag and pops the next byte from the hardware FIFO as a side effect, so a read you did "just to peek" actually consumes a byte that your real receive path then never sees, a dropped character. Similarly, reading some status registers clears sticky flags, and reading certain registers latches or advances internal state. The defensive practice is to read a register exactly once at the point you intend to consume its effect, store the value in a local if you need to examine it multiple times, and consult the datasheet's per-register access notes (which mark read-clear/read side effects). This is part of the broader rule that registers aren't normal memory: reads and writes can change hardware state, so every access must be deliberate.
Embedded Systems Fundamentals · Interview question
Why might reading a register "just to check it" be a bug?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Registers & Memory-Mapped I/O
How writing a memory address turns on an LED: control/status/data registers, the volatile register-overlay struct, and the write-1-to-clear and atomic set/reset traps.