method name for a long method

Question

The good style (Clean Code book) says that a method's name should describe what the method does. So for example if I have a method that verifies an address, stores it in a database, and sends an email, should the name be something such as verifyAddressAndStoreToDatabaseAndSendEmail(address);

or

verifyAddress_StoreToDatabase_SendEmail(address);

although I can divide that functionality in 3 methods, I'll still need a method to call these 3 methods. So a large method name is inevitable.

Having And named methods certainly describes what the method does, but IMO it's not very readable as names can be very very large. How would you solve it?

EDIT: Maybe I could use fluent style to decompose the method name such as:

verifyAddress(address).storeToDatabase().sendEmail();

but I need a way to ensure the order of invocation. Maybe by using the state pattern, but this causes the code to grow.

You do 3 things, Ok, think about a name that describes what you are doing by calling these 3 steps. Does it have a name? ok that's the method name — Hernán Eche, Sep 15 '11 at 20:54
I agree with Hernan. When I have multiple steps in doing something, there's always an overall goal. If it's not specific enough, there's always the generic goals such as processing. In your case, a processAddress(address) method can call your 3 separate steps in their respective methods. — Teddy Yueh, Sep 15 '11 at 20:59
but `processAddress` is very generic, IMO doesn't say nothing to the reader about the purspose of the method. — ejaenv, Sep 15 '11 at 21:17

score 6 · Answer 1 · answered Sep 15 '11 at 20:55

6

How I approach this is to make the 3 smaller methods as you mentioned and then in the higher method that calls the 3 smaller ones, I name it after the "why" I need to do those three things.

Try to define why you need to do those steps and use that as the basis of the method name.

answered Sep 15 '11 at 20:55

JamesEggers

12,885
14
59
86

Fleshing out this suggestion, I'd go with a public method `SaveAddress` that calls three private methods: `verifyAddress`, `insertAddress`, and `sendEmail`. – Rick Liddle Sep 15 '11 at 20:57
@Rick, but naming it `SaveAdress` doesn't say nothing about the colateral effect of sending an email. – ejaenv Sep 15 '11 at 21:19
1

@ejaenv one way to look at it would be naming it something like `HandleSaveAddressRequest` or something like that. If the why doesn't make sense, then sometimes describing the purpose or action as if working with events could be an alternative solution. – JamesEggers Sep 16 '11 at 15:48

score 2 · Answer 2 · answered Sep 15 '11 at 20:53

2

A single method should not do 3 things. Thus divide the work into 3 methods:

verifyAddress
storeAddress
sendEmail

answered Sep 15 '11 at 20:53

Todd Moses

10,969
10
47
65

1

but as I said, at some point you will need to call these 3 things toghether. (BTW what the Single Responsability Principle says is that a method should do one thing, but this one thing refers to a level of abstraction) – ejaenv Sep 15 '11 at 21:15

score 2 · Answer 3 · answered Sep 16 '11 at 00:00

I'm following up on my previous comment, but I've got more here than would fit reasonably in a comment so I'm answering.

The details of the method belong in the documentation not in the name of the method (in my opinion). Think of it this way... By putting SendEmail in the name of the method, you're committing implementation details to the method name. What if a decision is made down the road to send notification via SMS or twitter or something else instead of email? Do you change the name of the method and break your API, or do you have a method name that misleads the consumers of the API? Something to consider.

If you insist on keeping the functionality of the method in its name, I'd urge you to find something more generic. Perhaps something along the lines of VerifySaveAndNotify(Address address). That way, the method name tells you what it's doing without specifying how it does it. The parameter of type Address let's you know what is being verified and saved. All of that works together to make your method name informative, flexible, and terse.

score 0 · Answer 4 · edited Jun 20 '20 at 09:12

EDIT: Maybe I could use fluent style to decompose the method name such as:

verifyAddress(address).storeToDatabase().sendEmail();

but I need a way to ensure the order of invocation. Maybe by using the state pattern, but this causes the code to grow.

To ensure ordering of commands in a fluent style, each result would be an object that exposes only the functionality required by the next step. For example:

public class Verifier
{
    public DataStorer VerifyAddress(string address)
    { 
        ...
        return new DataStorer(address);
    }
}

public class DataStorer
{
    public Emailer StoreToDataBase()
    {
        ...
        return new Emailer(...);
    }
}

public class Emailer
{
    public void SendEmail()
    {
        ...
    }
}

This is handy if you need to create a very granular design and want to optimise your classes for reuseability, but is likely to be design overkill under most circumstances. Better probably as others have said to choose a name that represents what the whole process is supposed to represent. You could simply call it "StoreAndEmail", making an assumption that verification is something you do routinely before committing data to any destination. The alternative if you don't mind names being long is to simply describe it in full and accept that a long name is necessary. In the end, it really doesn't cost you anything, but can certainly make you code more specific in its intent.

method name for a long method

4 Answers4