4 ms·

Thanks. Your attitude sounds reasonable. Being honest though, one problem is that I do not consider it a personal preference: I basically think that functions l

Thanks. Your attitude sounds reasonable. Being honest though, one problem is that I do not consider it a personal preference: I basically think that functions longer than 100 lines are completely, and objectively, unacceptable (I wouldn't normally write a function longer than, say 30 lines). They are just woefully failing to take advantage of modularity, and modularity is the entire basis of the software revolution in the last 60 years. I recognize that I should try not to have overly strong feelings about a subject that some consider a matter of taste, but I don't think I'm alone here.

fjfaase 3y ago
And what is your attitude when you in some project come across a method longer than 100 lines? Do you immediately start cutting it into a bunch of smaller methods passing long list of input/output parameters? Or even turn it into a class to contain all the local variables? Or do you immediately perform a git blame and confront the developer who wrote the code to lecture them or force them to rewrite the code? Or do you think: I would not have written it like that and it might result in some technical debt, but at the moment it just works, and I just forget about it for the time being?
- neonsunset 3y ago
  (I have deleted my comment because reading adjacent comments made me realize it's not a productive conversation)
  - da39a3ee 3y ago
    There are answers to that scattered throughout this thread. Essentially, long functions are not taking advantage of modularity. And modularity is how we make complex things understandable, testable, and reliable.
- da39a3ee 3y ago
  It depends whether the function is conceptually important to the project and will be read a lot by colleagues, e.g. new team members who are learning the codebase. If not, then a bit like your last option (forget about it). But if it is important, then... that's the problem. I consider it a real problem. But it punctures colleagues' egos to have it pointed out that their code, while correct and effective, is actually not very well written. And colleagues in programming tend to have large egos that put up a forceful defense when they are being punctured.

fjfaase 3y ago

And what is your attitude when you in some project come across a method longer than 100 lines? Do you immediately start cutting it into a bunch of smaller methods passing long list of input/output parameters? Or even turn it into a class to contain all the local variables? Or do you immediately perform a git blame and confront the developer who wrote the code to lecture them or force them to rewrite the code? Or do you think: I would not have written it like that and it might result in some technical debt, but at the moment it just works, and I just forget about it for the time being?

neonsunset 3y ago
(I have deleted my comment because reading adjacent comments made me realize it's not a productive conversation)
- da39a3ee 3y ago
  There are answers to that scattered throughout this thread. Essentially, long functions are not taking advantage of modularity. And modularity is how we make complex things understandable, testable, and reliable.
da39a3ee 3y ago
It depends whether the function is conceptually important to the project and will be read a lot by colleagues, e.g. new team members who are learning the codebase. If not, then a bit like your last option (forget about it). But if it is important, then... that's the problem. I consider it a real problem. But it punctures colleagues' egos to have it pointed out that their code, while correct and effective, is actually not very well written. And colleagues in programming tend to have large egos that put up a forceful defense when they are being punctured.