One thing that is most often forgotten when documenting - and which is impossible to convey with variable names - is reasons.

When you pick up code 6 months or maybe 6 years later, you want to know why a block of code does something. General C knowledge should be able to tell what the code does, but it may be almost impossible to deduce the reason.

I can see code having a delay of 200ms. But I can never manage to figure out why 200ms was selected.

I may be able to see code light a specific LED, but I may not be able to figure out why. Maybe the LED information has to match something in a user manual, but without corresponding information in the code, it will impossible to know.

I can see code specify a 20 character large array for text input, but how do I know if 20 is a good size?

How was the size of a UART receive ring buffer decided? Based on what maximum baudrate? Based on what maxmimum poll interval? Based on a knowledge that the received data may arrive quickly but always in short burst, giving the processor time to catch up?

Reasons and assumptions are the absolutely most important comments, since it is so hard - or impossible - to reverse-engineer this information from the code even if each symbol name is 30 characters long.