The other day I was trying to google some articles on Scissors Rule so I could explain it in my StackOwerflow comment but I found out there is no google search result :) .

I first learned about Scissors Rule from Robet C. Martin in his screencasts Clean Coder.

The rule is from old days where programers where styling the code in a way that public methods / interface methods were at the top of the code and private methods were at the bottom. So if you theoretically print the source code of a file and you can cut it with scissors in half. This way you will end up with list of public methods so that other programers / developers can implement them in their code.

Does it have to be at top ?

User TurquoiseTurkey in a Reddit Discussion on this toppic had really good point:

I always put the public functions at the bottom of the file and the static ones at the top, so I don’t have to use forward declarations.

The rule is not about placing them only at the top, but having them in one place (Top or Bottom whatever is the best practice in your language) so that other developers implement your code much easily and they don’t end up jumping around the file to find all public interface methods.

One more thing I want to point out to avoid confusion:

The rule is not about placing public methods on the very top / bottom of a file Nope it’s just about not mixing public and private methods.

Here is an example from Ruby Style Guide on the topic: “how to organize Ruby classes”:

class Person # extend and include mixins extend SomeModule include AnotherModule # inner classes CustomErrorKlass = Class.new(StandardError) # constants SOME_CONSTANT = 20 # attribute macros attr_reader :name # other macros validates :name # public class methods def self.some_method end # initialization goes between class methods and other instance methods def initialize end # followed by other public instance methods def some_method end # protected and private methods are grouped near the end protected def some_protected_method end private def some_private_method end end

As you can see class has many different declarations before the public interface starts, yet this still comply with scissor rule.

How much useful is it these days ?

Well depend on what’s your opinion on private methods in general. Are you using them ? Are you trying to clearly point out to other developers which are the “stable” public interface methods and which are the “unstable” private methods that are target of functionality change.

I’m a Ruby developer that is trying to comply with Clean Coder principles (meaning I respect public / private separation) so for me scissor rule is a good guide.

Plus, Ruby has this in place by default (not sure if that was intention doh):

class Foo attr_reader :number def initialize(number) @number = number end def call do_some_stuff do_some_other_stuff end private def do_some_stuff @number = number + 100 end def do_some_other_stuff @number = number + 50 end end foo = Foo.new(2) foo.public_methods(false) # => [:number, :call] foo.number # => 2 foo.call foo.number # => 152

Ruby on Rails framework best practices goes even further and recommend to add extra level of indentation bellow private, so that developer browsing the code clearly notice that the context of methods changed

class Foo attr_reader :number def initialize(number) @number = number end def call do_some_stuff do_some_other_stuff end private def do_some_stuff @number = number + 100 end def do_some_other_stuff @number = number + 50 end end

So the scissors rule is already in place for Ruby developers. And to be honest it’s not that bad idea. The code is more readable.

That’s why I’m always trying to fallow it when I’m using other languages.

I wouldn’t call this “rule” a rule but more a recommendation. Sometimes you need to do stuff that will break this convention. But in general if you have two ways how to do same piece of functional code, with same performance and same readability but one is not fallowing the scissors rule and other is, I would go with the one that comply with the rule :)

private vs public

If you want to learn more about why public - private is important I’m recommending you to read Practical Object-Oriented Design in Ruby by Sandi Metz or watch formerly mentioned Clean Coders Screencasts (from what I remember first two or three episodes are talking about importance of the well structured code)

But the main point is that your public methods suppose to be the “stable methods” that you won’t change that often (e.g. change arguments), so that other developers can relly on your class. Private methods are the one you can go nuts in refatroring, change attributes, add functionality, improving benchmarks and so on.

The scissors rule just adds a cherry on top of it by making the class clear enough visually. So you won’t end up doing something like this:

class Foo attr_reader :number def initialize(number) @number = number end def call do_some_stuff do_some_other_stuff end def do_some_stuff @number = number + 100 end private :do_some_stuff def do_some_other_stuff @number = number + 50 end private :do_some_other_stuff def diffeent_call something_different end def something_different end private :something_different end Foo.new(2).public_methods(false) #=> [:number, :call, :diffeent_call]

Context indented methods

Reddit user mirhagk responded to the discussion with this point:

For myself I tend to structure most classes with related methods together, even if one is public and the other is private

I seen this before (again in Clean Coders screencasts) where the developer done same thing plus he actually indented methods depending on the level of calling.

For example if you have public_method calling private_method_1 and that is calling private_method_2

For example the abbove example could be written like this:

class Foo attr_reader :number private :do_some_other_stuff, :do_some_stuff, :something_different, :something_more_different def initialize(number) @number = number end def call do_some_stuff do_some_other_stuff end def do_some_stuff @number = number + 100 end def do_some_other_stuff @number = number + 50 end def diffeent_call something_different # ... end def something_different something_more_different # ... end def something_more_different # ... end end

And it’s a really good point and I fully agree that this is good approach in some languages, specially if you writing something in functional programing style.

It’s realy about the Language you are using and how flexible it’s syntax is.

I personally don’t recommend it in Ruby as it’s killing Ruby’s elegance.

But if you really want to write the code this way maybe combine both rules. Write public methods to top and indent private methods to their context.

class Foo attr_reader :number def initialize(number) @number = number end def call do_some_stuff do_some_other_stuff end def diffeent_call something_different end private def do_some_stuff # ... end def do_some_other_stuff # ... end def something_different something_more_different # ... end def something_more_different something_more_more_different # ... end def something_more_more_different # ... end end

If you have this code in any Object Oriented Language in 90% of casses you missed an abstration, meaning that the class has too many responsibilities and therefore some parts shoud be extracted to a different classes or the class should be actually two separate classes:

class FooStuff attr_reader :number def initialize(number) @number = number end def call do_some_stuff do_some_other_stuff end private def do_some_stuff # ... end def do_some_other_stuff # ... end end class FooDifferentStuff attr_reader :number def initialize(number) @number = number end def call something_more_different # .. end private def something_different something_more_different # ... end def something_more_different something_more_more_different # ... end def something_more_more_different # ... end end

Discussion and Sources

Thank you to all that joined the discussion on Reddit and reminded me of all the stuff I forgot to mention in the article.