[llvm-dev] Style: getFoo() vs foo()

[Dean Michael Berris via llvm-dev]

> On 25 May 2018, at 00:14, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 24.05.2018 13:11, Dean Michael Berris via llvm-dev wrote:
>>> On 24 May 2018, at 20:19, Sam McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> The coding guidelines say:
>>>> Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()).
>>> 
>>> This means that functions that just compute or access a value (no side-effects) should be named e.g. `getParent()`, rather than `parent()` as they are in e.g. the standard library.
>>> 
>>> This is not a rule that is particularly strictly observed in practice :-)
>>> Personally I find it adds noise and obscures the important difference between functions called mostly for their side-effects and those called to get at a value.
>>> 
>>> Swift's coding guidelines state this quite concisely:
>>>> Name functions and methods according to their side-effects
>>>> Those without side-effects should read as noun phrases, e.g. x.distance(to: y), i.successor().
>>>> Those with side-effects should read as imperative verb phrases, e.g., print(x), x.sort(), x.append(y).
>>> (https://swift.org/documentation/api-design-guidelines/#strive-for-fluent-usage)
>>> 
>>> How do people feel about this change? Clearly a mix of these styles will exist in practice for a long time (this is already the case!) but which should be encouraged?
>>> 
>>> (*dons flame-retardant suit and mumbles something about Java*)
>> I like it, but only if this means we’re going to introduce churn for the public interfaces. I’m not sure this is actually worth the trouble to do, but more consistent rules just sound like better rules to me at least.
> 
> I assume there is a "not" missing in the first sentence there?

Oh my, yes you’re right — I meant “only if it means we’re *not* going to introduce churn for the public interfaces”.

> I'd also prefer not to have API churn just for the sake of minor stylistic issues.
> 

+1

-- Dean