[LLVMdev] lld coding style

shankarke shankarke at gmail.com
Sun Oct 5 12:24:15 PDT 2014

I think we should format code using LLVM coding conventions, much easier to
follow and maintain. I think lldb also could consider moving towards one
coding convention style.

On Sun, Oct 5, 2014 at 1:46 PM, Chandler Carruth-2 [via LLVM] <
ml-node+s1065342n73136h99 at n5.nabble.com> wrote:

> On Sun, Oct 5, 2014 at 9:37 AM, Renato Golin <[hidden email]
> <http://user/SendEmail.jtp?type=node&node=73136&i=0>> wrote:
>> On 5 October 2014 07:19, Saleem Abdulrasool <[hidden email]
>> <http://user/SendEmail.jtp?type=node&node=73136&i=1>> 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.
> _______________________________________________
> LLVM Developers mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=73136&i=2>
>   http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
> http://llvm.1065342.n5.nabble.com/lld-coding-style-tp73133p73136.html
>  To start a new topic under LLVM - Dev, email
> ml-node+s1065342n3h76 at n5.nabble.com
> To unsubscribe from LLVM - Dev, click here
> <http://llvm.1065342.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3&code=c2hhbmthcmtlQGdtYWlsLmNvbXwzfDY4NzQ5MzE3NQ==>
> .
> <http://llvm.1065342.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

View this message in context: http://llvm.1065342.n5.nabble.com/lld-coding-style-tp73133p73138.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141005/c198d7b6/attachment.html>

More information about the llvm-dev mailing list