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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

韩玉 via llvm-dev
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).

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*)

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

韩玉 via llvm-dev

> On 24 May 2018, at 20:19, Sam McCall via llvm-dev <[hidden email]> 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.

-- Dean

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

韩玉 via llvm-dev
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 <[hidden email]> 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? I'd also
prefer not to have API churn just for the sake of minor stylistic issues.

Cheers,
Nicolai



>
> -- Dean
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

韩玉 via llvm-dev


> On 25 May 2018, at 00:14, Nicolai Hähnle via llvm-dev <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

韩玉 via llvm-dev
In reply to this post by 韩玉 via llvm-dev
Oops, +cfe-dev for more opinions.
Original message:
On Thu, May 24, 2018 at 12:19 PM Sam McCall <[hidden email]> 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).

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*)


On Thu, May 24, 2018 at 4:42 PM Dean Michael Berris via llvm-dev <[hidden email]> wrote:
> On 25 May 2018, at 00:14, Nicolai Hähnle via llvm-dev <[hidden email]> wrote:
> On 24.05.2018 13:11, Dean Michael Berris via llvm-dev wrote:
>> 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.
(Also agree with this FWIW) 
 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev