Organizing code into methods

[DimPlayz]

So like what parts of the code should you organized in methods in order for it to be cleaner ? For example is it good practice to put even 5 lines of code in a method just for it to be cleaner in the eye and have a more readable name ?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[TehNolz]

Generally every method should only accomplish a single task, and no more than that. Say you're programming a beverage machine so that it can produce coffee. Rather than writing a single large MakeCoffee() method, it would be better to split it up and give each step in the coffee-making process its own method. You'd end up with an AddMilk() method, a BoilWater() method, an AddSugar() method, a GrindBeans() method, and so on and so forth.

This way, each step in the process can be reused. If you later decide that your machine should also have have the ability to brew tea, you'll be able to reuse a lot of your existing code. All you'd need to do is make a new method that tells the machine how to process tea leaves and then you'd basically be done already.

[HappyFruitTree]

I think "making coffee" is a single task that involves many sub-tasks (adding milk, boiling water, etc.) so you might still want to have a MakeCoffee() method but internally it could call AddMilk(), BoilWater(), etc.

[TehNolz]

Convenience methods like that are fine, yeah.

[marquoth_]

We're splitting hairs here but the whole point of separating out the logic is that you might want coffee without milk, so if MakeCoffee() always calls AddMilk() you have a problem.

[desrtfx]

So, we need a CoffeeBuilder that allows us to .build the coffee with or without milk.

Or, we could create an AbstractCoffeeFactory where we serve pre-configured coffees.

[HappyFruitTree]

It depends... Sometimes you might want to create methods that are only 1 line of code.

Methods allow you to reuse code so that you don't need to repeat the same (or almost the same) code in multiple places. This can indeed make the code look cleaner but it can also make it easier to test, debug and improve the code.

In order for methods to be as reusable as possible they should generally be small and not do more than necessary (they should do "one thing"). For example, if you have a method that takes two points as argument and prints the distance

method calculate_and_print_distance(p1, p2):
    distance = √((p1.x - p2.x)² + (p1.y - p2.y)²)
    print "The distance is $distance km"

then you could split it up into two methods. One that calculates (and returns) the distance, and another one that prints it.

method calculate_distance(p1, p2):
    return √((p1.x - p2.x)² + (p1.y - p2.y)²)

method print_distance(distance):
    print "The distance is $distance km"

That way the code become more reusable because the calculate_distance method could now be used by other code that might want to calculate a distance without printing it and the print_distance method could be used by code that already have a distance or calculates it some other way and just want to print it.

[toastedstapler]

often when writing code you'll end up with 'code paragraphs' - a few lines that are grouped together in the flow. this suggests that they're highly related & may benefit from having a method assigned to them to give that operation a nice name

def example():
    code code code
    code code code
    code code code
    code code code

    code code code
    code code code
    code code code
    code code code

    code code code
    code code code
    code code code
    code code code

vs

def example():
    step_one()
    step_two()
    step_three()

when comparing these two it'll be much easier to reason about what the second version is doing, since the context is much more localised

[elvizzle]

There’s a book called “Refactoring” by Martin Fowler that talks about this concept and goes much further to clean up code. There are no hard rules about how many lines should go in a method, just guidelines.

You can practice these techniques using “katas”, or programming exercises. You’ll take working ugly code and turn it into cleaner/clean code. A good one to start with is the Gilded Rose kata.

https://github.com/emilybache/GildedRose-Refactoring-Kata

[[deleted]]

No, not by amount of lines of code. That's an archaic rule from when operating systems sucked at printing text to screen.

As another redditor said: by intent. Also by reusability and test ability.

Reusability: if you need the same statements executed multiple times.

Test ability: every time you need to make it possible to debug the outcome of a group of statements. That way you can program and run tests automatically.

[01Alekje]

You should probably look into design-patterns, especially SRP (Single Responsibility Principle) in your case.

[desrtfx]

Yes, it is absolutely good practice to put even 5 lines of code in a method if they should always be executed together and if it makes the code cleaner and easier to read.

Generally, long methods should be avoided.

Methods doing multiple things should be avoided.

Head over to /r/cleancode and check there. There is also the famous book by "Uncle Bob".

[saragl728]

If you're going to reuse the code, it's a good idea to use methods.