Is this the right naming convention ?

Question

Assuming we have a method which calls another.

public readXMLFile()  {
    // reading each line and parsing each line to return node.
   Node = parse(line);
}

private parse() {

}

Now is it a good practice to use a more comprehensive function name like "readXMLFileAndParse" ? Pro's: It provides a more comprehensive information to caller of what the function is supposed to be doing. Else client may wonder if it only reads where is the "parse" utility.

In other words I see a clear advantage of a function name to be comprehensive of all the activities nested within it. Is this right thing to do aka is this considered a good practice ?

Answer 1

It's a guideline that every method can only have one job (single responsibility). However this will cause problems for the naming where a method will return a result of a combination of sub-methods.

Therefore you should name it to describe its primary function: parsing a file. Reading a file is part of that, but it's not vital to the end-user since it's implicated.

Then again, you have to think of what this exactly entails: nobody just parses a file just to parse it. Do you retrieve data? Do you write data?

You should describe your actions on that file, but not as literally as 'readfile' or 'parsefile'. RetrieveCustomers if you're reading customers would be a lot more descriptive.

public List<Customer> RetrieveCustomers() {
 // loop over lines
 // call parser
}

private Customer ParseCustomer() { }

If you'd share what exactly it is you're trying to parse, that would help a lot.

Answer 2

I think it depends on the complexity of your class. Since the method is private, no-one, in theory, should care. Named it descriptively enough so you can read your own code 6 months from now, and stop there.

public methods, on the other hand, should be well-named and well-documented. Extra descriptiveness there can't hurt.