LOC of individual functions

[fabric-and-ink]

It would be great to have a lint for "long functions". This lint would count the number of lines (without comments) for each function and print a warning if it is larger than some value. The warnings may help to improve code readability in addition to the cyclomatic complexity lint.

[snowsignal]

By 'lines', do you mean the number of newlines the function body contains (minus comment lines) or do you mean the total amount of statements the function body contains?

[fabric-and-ink]

No, not the total number of statements. Just the number of non-empty lines that are not comments. They are a good simple measure for determining when a function body should be split up into separate functions. If I remember correctly, the maintainers of the linux kernel are not accepting functions that are longer than "two pages". I personally think when you reach more than 50 lines it is time to move individual parts out. Of course one could cheat and make very long lines but this would be a separate issue. In combination with rustfmt this would not work anyway.

Link to related rust project. Famous person's opinion on the topic.

[snowsignal]

So we should measure the number of newlines inside a function body, not counting them if there is no space between that and the previous newline, or if the start of the line is a comment tag or inside a comment body, and see if that number is less than 50, and if not we inform them that they should refactor the function? Good idea. What do you think should be the message that informs the programmer that their function is too long?

[fabric-and-ink]

Yes, precisely. Hmm, maybe something like "The function {$fn_name} seems to be rather long. Try to refactor it into smaller functions to improve readability."?

[oli-obk]

Bonus points for suggesting a place where to split the function. Somewhere where as few arguments as possible are needed, but the function is also sufficiently separated (like not suggesting to split off the last statement in a function or something).

Or splitting out subsections of a function. This will probably require some dataflow analysis on MIR.

[fabric-and-ink]

Haha, in that case the E-hard label would really be appropriate. And you probably could write a nice paper about the algorithm. But this isn't necessary. There should be some creative work left for the developer.

[snowsignal]

I think that the suggestion for where to split the function would be really cool, but that would be rather hard to implement. I think that we should implement the lint function that does a LOF check first, and then maybe make the recommended-split suggestion a separate lint function.

[gentoid]

Hello. I'm new to Rust, and I'd like to solve the easy part of this - check LOF

[oli-obk]

@gentoid great! Feel free to ask here or just open an unfinished PR if you have any questions.

[gentoid]

thanks @oli-obk ! Currently, I'm digging into it 😃 And it looks like the https://llogiq.github.io/2015/06/04/workflows.html post is still useful, despite the fact it points/uses outdated stuff sometimes