One of the issues regarding readability control is that readability is a subjective concept and thus difficult to rely on a general guideline plus devs' self governing to control. Some code review process has been designed to mitigate such risks and in my other post "Another way of coding explained" I also tried to establish some more objective standards for readability. The most effective way of controlling readability, however, is probably pair programming with regular pair switch while both devs in the pair always focus on readability.
Pairing means constant code review, but for readability control purpose, this is not enough. By definition, readability cannot be reviewed by the dev that wrote the code, because obviously if you wrote the code, you don't really need to read it. You already know all the rational behind the code and everything just makes sense to you. This why regular pair switching is also critical for readability control in pair programming.
By regular pair switch, I mean pair switch every 1-2 days so that most medium and plus size stories got implemented by more than 2 devs. Each switch means a little ramp up for the new dev that gets switched into the pair. The dev that remains on the pair needs to explain the story and all the existing code and design decisions with the new dev. This is a great opportunity to put the readability of the code under test. The new dev raises all readability issues he noticed when reading the code. The old dev does (or should do) the same thing when s/he finds some code more difficult to explain than others.
So this is another reason for regular pair switching and pair programming in general.