<div dir="ltr">Hi Daniel,<br><br>I'll try to elaborate a bit.<br><br>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).<br><br>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").<br><br>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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 24, 2014 at 5:39 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.).<div><br></div><div>Now, these costs aren't particularly high for the option you are suggesting, but I also don't understand the gain.</div><div><br></div><div><span style="font-size:13px">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?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Dec 24, 2014 at 11:25 PM, Adam McKee <span dir="ltr"><<a href="mailto:Adam.Matthew.McKee@gmail.com" target="_blank">Adam.Matthew.McKee@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi, list :)<br>
<br>
I'm new to clang-format, and I'm really impressed with this tool.  I<br>
think the value of an automated tool like this is so great, that I'll<br>
happily let it process all my code even if it doesn't do what I want<br>
100% of the time.  Most of the times when it's done something<br>
different from my habit, I've decided it actually looks better, and<br>
the only reason I wasn't formatting that way was because it would be a<br>
pain to do it manually.  Amazingly, there seems to only be one thing<br>
that makes me hesitate before running it on everything, and even this<br>
"issue" may not stop me from doing so.  I'd like to share my use case<br>
& suggested change, and see what you think.<br>
<br>
=== MY USE CASE<br>
<br>
I want to allow one-liner functions<br>
("AllowShortFunctionsOnASingleLine"), but if a function does not fit<br>
on one line I want to "BreakAfterDefinitionReturnType".  The<br>
configuration options don't seem to allow this, although they do what<br>
it says on the tin: "AlwaysBreakAfterReturnType" really means ALWAYS,<br>
but I don't want it always, I want it only if the function can't fit<br>
on a single line.  Is this actually possible now, or could it be done<br>
in a future version?<br>
<br>
=== MY SUGGESTED CHANGE<br>
<br>
My suggestion would be to remove "AlwaysBreakAfterReturnType", and add<br>
"BreakAfterReturnType" with three options: "always", "never", and<br>
"multiline", where "multiline" means break after return type if the<br>
function is not eligible for writing on a single line.  Is this a<br>
sensible request?  For clarity, "BreakAfterReturnType=multiline" would<br>
be equivalent to "BreakAfterReturnType=always" unless<br>
"AllowShortFunctionsOnASingleLine=true".<br>
<br>
Without this change, I think I'd probably turn off<br>
"AlwaysBreakAfterReturnType", but I'd like to have my return types on<br>
their own line & (as a higher priority) have my one-liners too if<br>
possible.<br>
<br>
Thanks for any advice :)  It's a great tool.<br>
<br>
-Adam<br></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>
</blockquote></div><br></div>