|Perl: the Markov chain saw|
If you see code that is displayed using <br /> tags, please don't "consider" the node for having <code> tags added. Such code is often rather ugly and can't be as easily downloaded, but it isn't really a hazard to navigation and the janitors have repeatedly demonstrated their lack of enthusiasm for such non-trivial modifications (having to remove tags from the end of every line and look for other HTML that might have to be modified, such as entities). And I'm glad that janitors have shown restraint in "fixing" such non-hazards.
Please feel free to /msg the author with such requests (politely, please). For anonymous nodes, the area is grayer, and you might "consider" such a node -- but I certainly don't think all such nodes.(anonymous nodes displaying code with <br /> tags) should be considered.
Code displayed in <pre> tags or many lines of code with no tags are different both in the seriousness of the problem and how easy it is to fix and so should eventually be considered.
Please also avoid using consideration for other minor imperfections that are not hazards to navigation. It becomes more appropriate to "consider" if the problem is more serious, if the amount of editting required to "fix" the imperfection is very small, and/or if the node was posted anonymously. But if it isn't a hazard to navigation, then janitors will likely not fix it (and likely shouldn't).
It is never appropriate to consider a node for a correction to content (that is, corrections beyong titles or formatting); janitors never correct spelling (outside of titles), grammar, programming, nor assertions, for example.
I also still don't see the value in reaping empty nodes. A reaped node is uglier than an empty node. And reaping prevents the node's owner from ever coming to their senses and putting something useful there, such as an informative or even educational explanation (see also (tye)Re: why a nodelet can be kept against author wish?).
Also note that seeing a particular type of consideration request in nodes to consider often means that such was a poor use of consideration. Appropriate consideration requests get processed more quickly, leaving the less-appropriate ones hanging around, often leading to copy-cat considerations. I've repeatedly heard "I thought that is what we do" from people who have followed a trend instead of the documented policies -- no, the documentation isn't perfect and does fall out-of-date at times, but the docs and threads w/ comments should provide better guidence than examples where you didn't see what got /msg'd to the considerer or didn't notice that the request was rejected.