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

[Sam McCall via cfe-dev]

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/cfe-dev/attachments/20180525/418b82e5/attachment.html>