<div dir="ltr">Great to hear! I will make this change to the style guide in the coming days if nobody objects further.<br><br>In the meantime, I would love for you guys (and anyone else for that matter) to try out clang-format. It would be great to work out any kinks in the existing rules file. For cases where there's a compelling enough reason, if clang-format doesn't support what we need, we can get it added. But for most things I think it should already either be correct in the existing rules file, or be fixable with a few tweaks and no modifications to clang-format itself.</div><br><div class="gmail_quote">On Mon Feb 09 2015 at 1:40:33 PM Kate Stone <<a href="mailto:katherine_stone@apple.com">katherine_stone@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Feb 9, 2015, at 12:45 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br><div><div dir="ltr">I was trying to give you the benefit of the doubt :) TBH I'd be even happier if we just use the LLVM rule consistently. But it's often easier for people to do this slowly. From your original response though it sounds like you might be fine just removing this rule and going with the LLVM style. If so, I'm definitely all for that.<br></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>This is completely consistent with what I’ve advocated for the team here: we deviate from the established LLVM convention for new code only in ways that are well-documented, consistently followed in the established code base, and for which we have a compelling rationale. I think sticking with LLVM style here makes the most sense.</div><div><br></div><div>Of course there will always be the temptation to make sure that minimal additions to existing files don’t stand out as egregiously different. Hopefully some common sense can be applied in these cases.</div><div><br></div><div><div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div style="font-family:LucidaGrande;word-wrap:break-word"><font color="#424242" style="font-family:'Lucida Grande';font-size:x-small">Kate Stone</font><span style="font-family:'Lucida Grande';font-size:x-small"> </span><font color="#009193" style="font-family:'Lucida Grande';font-size:x-small"><a href="mailto:k8stone@apple.com" target="_blank">k8stone@apple.com</a></font></div><div style="font-family:Times;word-wrap:break-word"><font face="Lucida Grande" size="1"><font color="#009193"></font> Xcode <font color="#424242">Runtime Analysis Tools</font></font></div></div></div></div></div><div><br></div><blockquote type="cite"><div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr"><div>If it makes you feel any better, I'm not crazy about some of their rules either. And actually they aren't even crazy about some of their rules. But it does help with consistency and readability for people who work across all of the codebases, and I think that kind of cross-project pollination is really helpful for the individual projects, as well as the community as a whole.</div></div><br><div class="gmail_quote">On Mon Feb 09 2015 at 12:06:25 PM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Feb 9, 2015, at 11:59 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon Feb 09 2015 at 11:56:44 AM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
><br>
> I actually do think that having the space between the complex visual noise of the argument list and the function name makes it easier to detect functions when scanning code, which was why we did it this way to start. That and from years of working on FSF code, Jason & I were used to it. It was a hard-and-fast rule for FSF code, but then for C++ this sort of thing:<br>
><br>
> target.GetProcess ().GetSelectedThread ().GetStackFrameAtIndex (0)<br>
><br>
> just looks stupid. So we don't use it there. I have a Quixotic desire to have some not hard-and-fast rules in the coding conventions, and rather to decide based on what looks good, because "I'm a free man, dammit!".<br>
><br>
> That's fine, and that's why I'm proposing just removing it from the style guide. Because leaving it in, and saying "We do this, but actually... not everyone does, but you can do it if you want!" is kind of redundant and unnecessary. Unfortunately clang-format, being a tool, does have hard and fast rules. So it seems like we can just say "do it if you want, but clang-format will remove it for you, and hopefully you use clang-format (because it has many other benefits as well)"<br>
<br>
That's a little problematic, because it's easier if the lldb style guide falls back to the llvm style guide on all the issues it doesn't specify. So if we leave the line out, then that should mean use the llvm rule.<br>
<br>
Jim<br>
<br>
<br>
</blockquote></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>
_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br></div></blockquote></div></div></blockquote></div>