Best practice for structuring of code: splitting up and arranging of methods

Hi,

I’m curious for some insight or best practice regarding how to best structure Ruby code. I sometimes split larger methods up into smaller ones and end up with something similar to this:

···

~~~
def method
  m1
  m2
end

def m1
  m1_1
  m1_2
end

def m2
  m2_1
  m2_2
end
~~~

Is there anything 'bad‘ from a coding style point of view (code smell or anti pattern) about this? If not, how would an experienced Ruby developer expect the method definitions to be arranged within the source code? First level first: m1, m2, m1_1, m1_2, m2_1, m2_2; or ‚following the narrative’: m1, m1_1, m1_2, m2, m2_1, m2_2?

Many thanks!

Cheers,
Michael

I’m curious for some insight or best practice regarding how to best structure Ruby code. I sometimes split larger methods up into smaller ones and end up with something similar to this:

~~~
def method
  m1
  m2
end

def m1
  m1_1
  m1_2
end

def m2
  m2_1
  m2_2
end
~~~

Is there anything 'bad‘ from a coding style point of view (code smell or anti pattern) about this?

That example presents too little information to answer that question.
Of course, there is generally nothing wrong with splitting up
functionality across multiple methods or even classes. That's all
programming is about, right? Whether it makes sense in your case
(which we do not know) we cannot tell.

If not, how would an experienced Ruby developer expect the method definitions to be arranged within the source code? First level first: m1, m2, m1_1, m1_2, m2_1, m2_2; or ‚following the narrative’: m1, m1_1, m1_2, m2, m2_1, m2_2?

I guess you can find arguments for either way. What usually matters
more than specific rules is consistency of rules applied. Maybe you
are over thinking this and should just try it out and see what works
best for you or your team.

Kind regards

robert

···

On Sat, Jun 25, 2016 at 11:04 PM, Michael Schwarze <michael@schwarze-web.de> wrote:

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

Hi Robert,

That example presents too little information to answer that question.

You are right; I had no special problem, just this general thought which often came to my mind.

What usually matters more than specific rules is consistency of rules applied.

Well, based on the little information I gave that’s actually great advice; so no »secrect« best practice about how to arrange methods within a Ruby class, but sticking to one way or the other and finding my own way.

Thank you!

Regards,
Michael

···

Am 26.06.2016 um 11:32 schrieb Robert Klemme <shortcutter@googlemail.com>:

Hi Michael,

When considering the design of a class think always about the public
interface in first place.
Those are the methods that matter and the ones that should be under unit
tests.
Then with tests in place you are free to create whatever private methods
you would like.
Private methods are not part of the contract, so you are free to play with
them as much as you like,

This is just a little principle I use in my designs. Hope it helps.

Happy ruby coding,

Daniel

···

On Sunday, 26 June 2016, Michael Schwarze <michael@schwarze-web.de> wrote:

Hi Robert,

> Am 26.06.2016 um 11:32 schrieb Robert Klemme <shortcutter@googlemail.com
<javascript:;>>:

> That example presents too little information to answer that question.

You are right; I had no special problem, just this general thought which
often came to my mind.

> What usually matters more than specific rules is consistency of rules
applied.

Well, based on the little information I gave that’s actually great advice;
so no »secrect« best practice about how to arrange methods within a Ruby
class, but sticking to one way or the other and finding my own way.

Thank you!

Regards,
Michael

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org <javascript:;>
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;