The coding guidelines say:> Function names should be verb phrases (as they represent actions), andcommand-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*) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180524/0ed1ce04/attachment.html>
Dean Michael Berris via llvm-dev
2018-May-24 11:11 UTC
[llvm-dev] Style: getFoo() vs foo()
> 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. -- Dean
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? I'd also prefer not to have API churn just for the sake of minor stylistic issues. Cheers, Nicolai> > -- Dean > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte.
Oops, +cfe-dev for more opinions. Original message: On Thu, May 24, 2018 at 12:19 PM Sam McCall <sammccall at google.com> 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*) >On Thu, May 24, 2018 at 4:42 PM Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > 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: > >> 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180525/418b82e5/attachment.html>