back

by locknitpicker·11d ago·view on hn ↗
> Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines.

Lines or code is an indicator, not a goal. If you write long-winded functions, your code is bug prone and harder to test and verify. If you refactor it, it gets shorter. Where do you draw the line?

The same goes for how many characters you accept between two line breaks. Some go for 76. Some for 130 or more. There is no difference if your line has 129 or 131 chatacters, but if you spew a comment with 999 characters in a single line then your feedback is actionable if you say "hey man, don't be that guy. Rewrite your comment and make it readable."

> (...) PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities.

Not really. Calling out basic things like "this function is far too long" is clear, objective, and actionable feedback. That is a good PR comment.

Dismissing clear and actionable feedback as some guys whims is a red flag, and a telltale sign of someone who has no interest to improve their output and address issues.

1 comments
I think what I intended to get across isn't too incompatible with what you're saying. I think it's fine to say "this function is too long", and long functions generally speaking should be something that's worthy of a code review comment.

I think the issue that originally launched this thread of the discussion is people who take the specific rules to a dogmatic level and apply rules blindly, and transform "functions should not be long" to "functions should be less than 20 lines no matter what". 20 lines (or whatever standard you land on) should be a guideline and not an inviolable law of the universe, and if reducing a method below 20 lines harms comprehensibility and readability, you're letting the guideline get in the way of the actual goal.