Community preference on code/the size of functions etc?

Maybe credo for code styling? Although I am not sure if it checks function length.

I think the only thing that works reliably is manual code review. Tools that check function length tend to become an obstacle to work around without actually improving the code.

I agree that generally the number of lines should be short but there are use cases where it makes more sense to have longer functions than splitting it up into multiple pieces. In my experience a developer struggling with writing functional code generally will not make the right decisions to make a function shorter and need help to get into the right way of thinking.

Credo is a great tool, which performs many of the functionality you’d use Rubocop for in Ruby-land.
The nice thing about it, is that there are many style-related issues it hints at by looking at what you (and other contributors to the project!) do: If everywhere you use two spaces for indentation but here you use four, then it will warn you about it. But if you use four everywhere, and use two spaces at one place, then you’ll be warned about that line instead.

As for checking for function size: Credo checks at least for cyclomatic complexity (source), which is a matric that is slightly more sophisticated than lines-of-code for a function.

At least you may skip a rule with rubocop, if you want to.

But still, in my preference, limiting a subroutine with small amount of code is better. Small function with single purpose, small classes/modules, etc, make them easier to read, refactor, document and test.

Cyclomatic complexity is different with function’s length.

Still, my question is not yet answered.

My personal preference is around 20.

This big:

___________________________
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-______________________________

Even though we do not do elixir in my company, there have been discussions about setting our linters to fixed body-lengths.

As we are using go and python as primary languages as well as puppet, docker and bash as secondary languages, we decided we can not agree on a limit that suites all of those languages, therefore we decided to not put a limit at all. But we do not merge without review. So if the reviewer is in doubt about the length, we need to discuss. But usually we refactor as soon as a single person is in doubt.

After about a year, we consider this superior over fixed linting rules, and after we learned to know each other better, we ran less and less in situations that did not pass review (because of function length).

A good starting point as a rule of thumb we discovered was: “Would it fit on Xs screen?” (X is actually me, when working from the park or coffee shop with my 14" laptop).

I think there is no sense to set a strict limit to the function size in immutable languages.

This book came out recently:

https://smile.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201

The author discusses how software design could be improved by increasing focus on how design decisions impact the system’s overall complexity.

You can watch a 1 hour talk the author gave about some of his ideas here. One thing he discusses is the idea that classes should be “deep” (see talk for definition), and in that context he touches on the “n lines rule” at 17:50.

Discussion of the book, and number of lines vs design is sprinkled throughout episode 20 of the Elixir Outlaws podcast, but is mentioned more specifically at 21:40.

To be clear: I’m just adding relevant sources to the discussion (I hope!), not taking sides

These answers really cotradict with what I’ve learned from Dave Thomas, Uncle Bob, Martin Fowler, etc.

This world is weird