I like what Robert Martin wrote in his book "Clean Code," which I think is an excellent book, and I don't often think or say that. Assuming I understand/remember his points correctly, he was very much into creating very short methods, with as few parameters in the method signature as possible, with highly readable method names. This made the code extremely readable. While it might take some time to refactor a 100 line method into 20 separate methods with clean names and 5 lines of code each on average, it does make for very readable and maintainable code.
I agree that comments can be helpful, especially for strange cases, but I also agree that they are not necessary if code is broken down into short, easy to understand, well-named methods. It makes the code much easier to understand and maintain and breaks down the intent to 5 to 10 easy to digest lines instead of 100 lines. It helps to make the comments less necessary.
I also feel that maintaining a lot of comments is a lot of extra time and effort, that many people do not have time to do or bother to do, especially when they update or change something later or if it is someone else's code. People start to ignore the comments because they can be inaccurate / out of date as time goes on.
Also each method should do exactly one thing, I believe, is a rule that was mentioned. I am not sure this is always easy or possible, but it makes each method's purpose clear and easy to comprehend if it can be accomplished.