I agree with the other answers in that usually there is no need for any fancy tool. I used to follow the "fits to the monitor at once" rule (with the extension that "using a normal size font, i.e. no smaller than 8pt", as one of my ex-coworkers used 6pt). That was in my practice about 30-50 lines max.
Then I read Clean Code and that pushed my threshold down to about 10 lines. But the main point is not really the lines of code, rather
- cohesion (each method doing one thing), and
- staying on the same level of abstraction (e.g. not calling high level API methods and doing bit flipping within the same method).
So most of my methods nowadays are at most 5 lines long, but occasionally some may be 25 when I can't see an easy way to refactor.
However, if you really need an objective metric, check out cyclomatic complexity. Some IDEs like IntelliJ have it built in their static code analysis tool.
If you want tool support to identify long methods or other code smells within a large legacy codebase, this metric may help you. But I usually prefer to focus on the areas I need to touch anyway. Since the reason to touch the code is a) there is a bug in there to fix, b) there is a feature to add, these tend to be the most critical code parts over the long term. There are typically lots of ugly code in other places of the system too, but as long as there are no known bugs in there and no business request to change anything there, there is little value in refactoring those parts.