4 ms·

Don't see a problem with one line functions per se, especially if the name of the function helps understanding the code

by tcfhgj 2y ago

arp242 2y ago
There no problem with them, and they can often be useful. But there is a problem if all the code is only functions of one or two lines, or when people move things to functions when it just doesn't make much sense, "because it's Best Practice™".
- pbw 2y ago
  Pylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc. For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines. I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written. A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically. So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.
  - LorenPechtel 2y ago
    Yup. I would like to keep things on the screen if feasible, but it's really always cyclomatic complexity that matters. A linear flow of lines, I don't care about until I can't see it all at once but you're rarely writing a linear flow of lines.
    - pbw 2y ago
      I always felt that true "scripting" with a "scripting language" was two things: 1) Most of your functions were linear: low cyclomatic complexity. 2) Functions rarely called into other functions. While "programming" moves away from both of those: 1) Higher cyclomatic complexity is allowed. 2) Functions frequently call into other functions. For instance, I like bash only for scripting. The moment it starts to resemble programming, I tend to switch to Python. However, some people are fine doing a fair amount of "programming" in bash, people who know it really well.
tetha 2y ago
Nah, short and single-line functions can be good. Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way that's obviously correct and consistent within itself. For example, currently I'm working on a bit of a backup analyzer to identify different problems, estimate sizes and such. One object in there is the PGBackrestState and it has a whole bunch of one-line methods like total_size_on_disk, full_backup_count, average_incemental_size. Most of these are just one list comprehension. That's nice, readable, correct and stable code - and it makes other code more readable. But some functions in that code base are an implementation of pretty much a flow chart of grabbing information, figuring out the state of the system and eventually dropping into more specific analyzers. This can be a whole bunch of imperative code in a function. And I've tried, but chopping this into smaller functions makes the overall idea and control flow much harder to understand. Sometimes a rough screen length of logic can be easier to understand as well.
- pbw 2y ago
  I mentioned in another comment pylint’s 50 line limit for methods. So I agree - a well written 50 line method is sometimes better than the same code chopped up. Although a significant factor is if you chopped it up, would there be multiple callers for the new smaller methods? Because that’s probably better than adding flags to your large method to make it behave differently for different callers, increasing its cyclomatic complexity.

Don't see a problem with one line functions per se, especially if the name of the function helps understanding the code

by tcfhgj 2y ago

Don't see a problem with one line functions per se, especially if the name of the function helps understanding the code

There no problem with them, and they can often be useful. But there is a problem if all the code is only functions of one or two lines, or when people move things to functions when it just doesn't make much sense, "because it's Best Practice™".

pbw 2y ago
Pylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc. For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines. I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written. A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically. So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.
- LorenPechtel 2y ago
  Yup. I would like to keep things on the screen if feasible, but it's really always cyclomatic complexity that matters. A linear flow of lines, I don't care about until I can't see it all at once but you're rarely writing a linear flow of lines.
  - pbw 2y ago
    I always felt that true "scripting" with a "scripting language" was two things: 1) Most of your functions were linear: low cyclomatic complexity. 2) Functions rarely called into other functions. While "programming" moves away from both of those: 1) Higher cyclomatic complexity is allowed. 2) Functions frequently call into other functions. For instance, I like bash only for scripting. The moment it starts to resemble programming, I tend to switch to Python. However, some people are fine doing a fair amount of "programming" in bash, people who know it really well.

tetha 2y ago

Nah, short and single-line functions can be good. Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way that's obviously correct and consistent within itself. For example, currently I'm working on a bit of a backup analyzer to identify different problems, estimate sizes and such. One object in there is the PGBackrestState and it has a whole bunch of one-line methods like total_size_on_disk, full_backup_count, average_incemental_size. Most of these are just one list comprehension. That's nice, readable, correct and stable code - and it makes other code more readable. But some functions in that code base are an implementation of pretty much a flow chart of grabbing information, figuring out the state of the system and eventually dropping into more specific analyzers. This can be a whole bunch of imperative code in a function. And I've tried, but chopping this into smaller functions makes the overall idea and control flow much harder to understand. Sometimes a rough screen length of logic can be easier to understand as well.

pbw 2y ago
I mentioned in another comment pylint’s 50 line limit for methods. So I agree - a well written 50 line method is sometimes better than the same code chopped up. Although a significant factor is if you chopped it up, would there be multiple callers for the new smaller methods? Because that’s probably better than adding flags to your large method to make it behave differently for different callers, increasing its cyclomatic complexity.