First you fix (3), by naming variables in a nice, descriptive way - that possibly causes violations of (2).
Then you fix (2), by having lines/statements that are clear and don't do ten things at once - that possibly causes violations of (1).
And then, you fix (1), by refactoring your methods properly - and that is a valid goal by itself.
If instead you have longer lines, then the problem of your method being too big doesn't go away, it still does the same thing, you just don't notice it. If (1)+(2)+(3) would force you to split up your methods, then that's an indication that those methods should be split up anyway, even if you choose to ignore (2) and (3) - "too many lines of code" is a code smell simply because it correlates to "does too much", and even a one-line method can possibly be doing too much, if it's written in code-golf-style.
First you fix (3), by naming variables in a nice, descriptive way - that possibly causes violations of (2).
Then you fix (2), by having lines/statements that are clear and don't do ten things at once - that possibly causes violations of (1).
And then, you fix (1), by refactoring your methods properly - and that is a valid goal by itself.
If instead you have longer lines, then the problem of your method being too big doesn't go away, it still does the same thing, you just don't notice it. If (1)+(2)+(3) would force you to split up your methods, then that's an indication that those methods should be split up anyway, even if you choose to ignore (2) and (3) - "too many lines of code" is a code smell simply because it correlates to "does too much", and even a one-line method can possibly be doing too much, if it's written in code-golf-style.