[cfe-dev] clang-format and PenaltyReturnTypeOnItsOwnLine?
Daniel Jasper
djasper at google.com
Mon Aug 19 02:08:02 PDT 2013
Yes, clang-format currently does not have an option that says "always break
after a function's return type". It should be fairly easy to add, though.
Does your coding style prescribe this for definitions only or also for
declarations?
On Sat, Aug 17, 2013 at 10:33 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> On Aug 16, 2013 9:31 PM, "Leif Hedstrom" <zwoop at apache.org> wrote:
> >
> > Hi all,
> >
> > Hope this is the right channel for this question :). I'm looking at
> possibly using clang-format to clean up an indentation / formatting style
> mess for a fairly large project (Apache Traffic Server). One of our
> "quirks" is that we currently format our functions like:
> >
> > inline const char*
> > some_func(int some_arg)
> > {
> > …
> > }
> >
> >
> > I've tried both
> >
> > PenaltyReturnTypeOnItsOwnLine: 0
> >
> > and
> >
> > PenaltyReturnTypeOnItsOwnLine: 10000
> >
> >
> > and various numbers in between, but it always formats the above like
> >
> > inline const char* some_func(int some_arg)
> > {
> > …
> > }
> >
> >
> > Maybe I'm misunderstanding what PenaltyReturnTypeOnItsOwnLine does?
>
> I assume it identifies the 'cost of splitting a line after the return.
> Relative costs of different splits are used in comparisons to decide on the
> optimal split - I doubt it'll change anything related to the behavior of
> the unsplit lines.
>
> > What's even more confusing is that if I use the "mozilla" predefined
> format, it still doesn't format it like I expect. And I'm 99% certain that
> Mozilla code also uses the "return type on its own line" formatting.
> >
> > Cheers!
> >
> > -- leif
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130819/13f5c882/attachment.html>
More information about the cfe-dev
mailing list