In spite of this possibly raising a holy war, I thought I would bring up this question again. When switching between a couple of LLVM repositories, I find having to switch between coding styles a bit of an annoyance. It always takes me a while to get adjusted when switching between LLVM (or clang) and lld. While not an absolute show stopper, not having such friction would be nicer. I realize that lld has had a fair amount of development and that means that it has a somewhat established codebase. However, having a single uniform style across the projects reduces the barrier to entry, encouraging more developers to work on various projects across the set. So with that in mind, I would like to ask, would it be possible to consider switching to LLVM style for lld? -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141004/541c7be1/attachment.html>
On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote:> So with that in mind, I would like to ask, would it be possible to consider > switching to LLVM style for lld?We don't usually enforce code styles on side projects because it doesn't make sense to do so. There are too many conflicts between developers, external source code, style-oriented commits that break the time-line of the project, that it's just not worth worrying about it. Not to mention that style is fashion, some like it this way, some like it that way. Code style changes with time. If the majority of lld developers agree with you that the current style is bad and needs to be changed (to a more LLVM-ish style), than future commits should move lld's style towards that. Not by adding new styles to one line inside an old function, but by deprecating style when you deprecate code, and creating style when you create code. It's also very likely that, by the time you have converted all old code with new style, the preferred style will have changed, and you'll want to do it all over again. To avoid that pointless race against nothing, we tend to keep the style that was in the original file/function and not mind much. Code style is like keyboard layout. Your first reaction is "what the f**?", then you get used to it, than you can switch between all keyboard styles (except AZERTY) without a problem. cheers, --renato
On Sun, Oct 5, 2014 at 9:37 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > > So with that in mind, I would like to ask, would it be possible to > consider > > switching to LLVM style for lld? > > We don't usually enforce code styles on side projects because it > doesn't make sense to do so.This is not completely accurate. Both LLD and LLDB were given specific exemptions from the coding standards, but Clang wasn't and I wouldn't expect a new subproject to *necessarily* get such an exemption. It might, it might not. I consider the current state with both LLD and LLDB a bug rather than a feature because it creates pointless and non-trivial disruption for developers to move between LLVM, Clang, LLD, and LLDB. You can argue that coding standards are like fashion, but *changing* coding standards is a much more pragmatic and real concern. At least one important point of LLVM's standards (in my mind and I suspect other developers' minds) is to drive consistency both within projects and across projects.> Code style changes with time. If the majority of lld developers agree > with you that the current style is bad and needs to be changed (to a > more LLVM-ish style),Figuring out whether most LLD devs want to switch seems like the point of the email?> than future commits should move lld's style > towards that. Not by adding new styles to one line inside an old > function, but by deprecating style when you deprecate code, and > creating style when you create code. >That is one option. But the developers of LLD may be willing to more aggressively convert. We should let them speak for themselves rather than hypothesizing here.> > It's also very likely that, by the time you have converted all old > code with new style, the preferred style will have changed, and you'll > want to do it all over again. To avoid that pointless race against > nothing, we tend to keep the style that was in the original > file/function and not mind much. >This has not been my experience in any part of the LLVM project. The coding standards are extremely stable these days. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141005/5650c965/attachment.html>
> So with that in mind, I would like to ask, would it be possible to consider > switching to LLVM style for lld?One particular feature of lld's current style is particularly dodgy: starting member variables with '_' makes undefined behaviour very easy to introduce (if the first real char is upper case; there's already plenty of examples). It's one of the more innocuous forms of UB, but still bad form for an LLVM project. If even we can't get it right... Cheers. Tim.
It is unfortunate that we are using a different coding scheme for LLD than LLVM, but I'm leaning toward the view that switching to LLVM style will cost too much if it means we are going to lose virtually all commit history. A patch to switch to LLVM style would rename all local and member variables, so it would touch all the lines. Diff is not powerful enough to trace the history beyond variable renaming. svn blame would become useless. I have no strong opinion on this. If many other LLD developers really want to make this happen, I can bear with that. It doesn't feel very productive thing to do to me, though. On Sun, Oct 5, 2014 at 2:26 PM, Tim Northover <t.p.northover at gmail.com> wrote:> > So with that in mind, I would like to ask, would it be possible to > consider > > switching to LLVM style for lld? > > One particular feature of lld's current style is particularly dodgy: > starting member variables with '_' makes undefined behaviour very easy > to introduce (if the first real char is upper case; there's already > plenty of examples). > > It's one of the more innocuous forms of UB, but still bad form for an > LLVM project. If even we can't get it right... > > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141006/85b5f65b/attachment.html>
On Oct 5, 2014, at 9:37 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> So with that in mind, I would like to ask, would it be possible to consider >> switching to LLVM style for lld? > > We don't usually enforce code styles on side projects because it > doesn't make sense to do so. There are too many conflicts between > developers, external source code, style-oriented commits that break > the time-line of the project, that it's just not worth worrying about > it. Not to mention that style is fashion, some like it this way, some > like it that way.The only case where this makes sense (that I’m aware of) is libc++, given that it is a very different (and highly constrained) domain. I think that lld and lldb following different coding standards is a serious bug, which increases friction within the community. I’d support progressively moving them to a style more similar to LLVM. -Chris
IMHO a much bigger problem is functions (throughout LLVM and Clang) that are still named starting with a capital letter. With LLD, the division is simple: "is this LLVM or LLD", and this doesn't cause much mental overhead (at least for me). But with the function name capitalization it's often much less obvious which one it should be (quick: does raw_ostream use capitalized function names? how about SourceMgr? How about clang's CodeGenFunction? or clang::Parser?). If I had one vote for a "change all the things" type renaming, I would most definitely put it towards fixing the function capitalization issue rather than changing LLD's naming convention. -- Sean Silva On Sat, Oct 4, 2014 at 11:19 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote:> In spite of this possibly raising a holy war, I thought I would bring up > this question again. > > When switching between a couple of LLVM repositories, I find having to > switch between coding styles a bit of an annoyance. It always takes me a > while to get adjusted when switching between LLVM (or clang) and lld. > While not an absolute show stopper, not having such friction would be nicer. > > I realize that lld has had a fair amount of development and that means > that it has a somewhat established codebase. However, having a single > uniform style across the projects reduces the barrier to entry, encouraging > more developers to work on various projects across the set. > > So with that in mind, I would like to ask, would it be possible to > consider switching to LLVM style for lld? > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/167eb76b/attachment.html>