I have working code that I want reviewed, but it is not clean. It made the correct output but there are comments and bad names. Is it not ready for review, and must the code be clean to get reviewed here?
No it doesn't have to be clean.
It can get reviewed, but people will point those problems out. If you know they are bad you should probably clean them, that way we won't badger on about them, and more about bits you don't know how to improve.
So it's best if you do clean it, but not a requirement.
Make the code as clean as you can before submitting it for review.
The more work you put into your code, the more you're likely to get out of review.
That's because reviewers (especially the volunteers here) have a limited amount of time and energy to put into a review. If they have to spend their time pointing out basic issues such as lack of documentation, misleadingly named variables, lack of functional decomposition, and so on (issues that you are probably already aware of), they are going to run out of time and enthusiasm before they consider more advanced issues.
If there's a problem with your code that you are aware of, and you submit the code for review without fixing it, then you're wasting everyone's time. Fix the problems first.
I generally agree with the first answer, but depending on the comments, people may point out something like "comments that do this indicate that the code is not ready for review." For example, if you have commented out code or comments that say things like "TODO: implement this feature".
That said, unclean code is not a close reason. Incomplete code might be.
This code can be posted here, but A) if you know there is a problem, you should fix it first, and B) comments are good as long as they are useful and tell the programmer something the code doesn't tell them. Examples of good comments are those explaining what the code is doing if it is doing something particularly unusual or unreadable that cannot be changed, or a detailed outline of the spec for a certain method explaining what it does and all the edge cases it must account for.
For example, if the code is doing something particularly nasty that is required for speed or another good reason, then there should be a comment explaining why it is doing it that way so nobody else changes it to a slower, more readable version.
If you have a method that must handle a situation with many slight variations, a good comment could be much longer than the method and will explain what exactly has to be done so it won't be changed to a "better" version that breaks one of the less common usages.