[cfe-dev] break after definition return type, but only if function can't be a one-liner?

[Adam McKee]

Hi Daniel,

I'll try to elaborate a bit.

I like one-liners whenever possible because many of my class declarations
contain a bunch of one-liners, and if those take 4 lines instead, when I'm
looking at that header file I'm not seeing as much of the class declaration
in front of me on a single screen, and I don't like how it looks when a
trivial function that "should" be one line (according to me) is gobbling up
screen space like that.  At the same time, for function definitions that
aren't simple one-liners, I prefer to have the return type on a separate
line because I find it easier to read & work with, and I get more room to
work with for "ClassName::MethodName(arg1_type arg1_name, ...)".  In a way
it does have to do with searching for function names: when I'm looking at
the code I spend the bulk of my time working with (i.e. not one-liners) I'm
accustomed to seeing the return type at the start of a line, and finding on
the next line "ClassName::MethodName(".  This is what my brain is used to
looking at -- finding return types & method names at column 0, *but* I like
the dead simple functions to be one-liners (particularly inside class
declarations, although we don't need to concern the tool with different
rules for inside class declaration vs. not).

I think I can only justify my preferences for the formatting up to a
point.  I think the usefulness of support for a given preference is
proportional to the number of users who share that preference.  In the case
of this change, there seems to not be a large % of users who want the
configuration I want.  However, as clang-format is more & more widely used
(which we can expect), the number of users who would configure it the way I
request could easily climb up well into the thousands.  I want to highlight
a positive aspect of this change, which is that the number of configuration
parameters is not increased.  This change only re-conceives an existing
parameter to make it more capable, and able to co-operate with another
existing parameter (whereas "AllowSimpleFunctionsOnASingleLine=true" is
currently made irrelevant by "AlwaysBreakAfterReturnType=true").

Without this change, I'd probably give up the one-liners in my class
declarations.  Anyway, great tool no matter what.  For some reason it was
surprising to find a tool that does such a nice job, and can come so close
to what I prefer (when not introducing me to new preferences) that I
actually may process every source file I ever wrote with it, and even
configure emacs to clang-format buffers just before saving.

On Wed, Dec 24, 2014 at 5:39 PM, Daniel Jasper <djasper at google.com> wrote:

> I am somewhat torn with regard to adding this option. Every additional
> option has a certain cost associated with it (harder discovery of options,
> more maintenance, more combinations of options that can lead to undesired
> behavior, etc.).
>
> Now, these costs aren't particularly high for the option you are
> suggesting, but I also don't understand the gain.
>
> AlwaysBreakAfterReturnType is mostly implemented to support GNU style. The
> rationale that GNU style gives for having this style is so that it becomes
> easier to grep for function names, navigate between functions, etc. This
> rationale certainly doesn't apply if you exclude single-line functions. If
> you don't care about grep'ing of function names, it seems fine to use what
> LLVM style does and break after the return type first (before breaking
> anywhere else). Can you elaborate on why you think that your proposed style
> is useful?
>
> On Wed, Dec 24, 2014 at 11:25 PM, Adam McKee <Adam.Matthew.McKee at gmail.com
> > wrote:
>
>> Hi, list :)
>>
>> I'm new to clang-format, and I'm really impressed with this tool.  I
>> think the value of an automated tool like this is so great, that I'll
>> happily let it process all my code even if it doesn't do what I want
>> 100% of the time.  Most of the times when it's done something
>> different from my habit, I've decided it actually looks better, and
>> the only reason I wasn't formatting that way was because it would be a
>> pain to do it manually.  Amazingly, there seems to only be one thing
>> that makes me hesitate before running it on everything, and even this
>> "issue" may not stop me from doing so.  I'd like to share my use case
>> & suggested change, and see what you think.
>>
>> === MY USE CASE
>>
>> I want to allow one-liner functions
>> ("AllowShortFunctionsOnASingleLine"), but if a function does not fit
>> on one line I want to "BreakAfterDefinitionReturnType".  The
>> configuration options don't seem to allow this, although they do what
>> it says on the tin: "AlwaysBreakAfterReturnType" really means ALWAYS,
>> but I don't want it always, I want it only if the function can't fit
>> on a single line.  Is this actually possible now, or could it be done
>> in a future version?
>>
>> === MY SUGGESTED CHANGE
>>
>> My suggestion would be to remove "AlwaysBreakAfterReturnType", and add
>> "BreakAfterReturnType" with three options: "always", "never", and
>> "multiline", where "multiline" means break after return type if the
>> function is not eligible for writing on a single line.  Is this a
>> sensible request?  For clarity, "BreakAfterReturnType=multiline" would
>> be equivalent to "BreakAfterReturnType=always" unless
>> "AllowShortFunctionsOnASingleLine=true".
>>
>> Without this change, I think I'd probably turn off
>> "AlwaysBreakAfterReturnType", but I'd like to have my return types on
>> their own line & (as a higher priority) have my one-liners too if
>> possible.
>>
>> Thanks for any advice :)  It's a great tool.
>>
>> -Adam
>> _______________________________________________
>> 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/20141224/5986ea3a/attachment.html>