Great to hear! I will make this change to the style guide in the coming days if nobody objects further.
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. On Mon Feb 09 2015 at 1:40:33 PM Kate Stone <katherine_st...@apple.com> wrote: > On Feb 9, 2015, at 12:45 PM, Zachary Turner <ztur...@google.com> wrote: > > 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. > > > 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. > > 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. > > Kate Stone k8st...@apple.com > Xcode Runtime Analysis Tools > > 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. > > On Mon Feb 09 2015 at 12:06:25 PM <jing...@apple.com> wrote: > >> >> > On Feb 9, 2015, at 11:59 AM, Zachary Turner <ztur...@google.com> wrote: >> > >> > >> > >> > On Mon Feb 09 2015 at 11:56:44 AM <jing...@apple.com> wrote: >> > >> > 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: >> > >> > target.GetProcess ().GetSelectedThread ().GetStackFrameAtIndex (0) >> > >> > 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!". >> > >> > 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)" >> >> 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. >> >> Jim >> >> >> _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
