Note, we tend to be much more concerned about the naming of things than the
aligning of them.
Among other things it should be clear orthographically whether something is an
ivar/local/global. Also except for types that come from the system (and a few
analogous ones like lldb::addr_t), types & variables should be distinct, which
we do by having variables start with lower case letters and types upper case.
And give descriptive names for things. It really helps if I can look at a line
of code and figure out from the variable names on the line what the line is
doing. A corollary of this is unless the use is very obvious, resist the
temptation to use one-letter variable names. We seem to use "s" for streams,
but other than that we're pretty good about this.
Another important rule is always call the same thing the same name. That way
if I want to look for how something is used, I can search the code for that
name & I'll come up with a bunch of useful hits. If you choose a good name for
the thing, then reusing it will be obvious. If you call things "a" or "b" or
"variable" then you won't be able to do this.
Jim
> On Aug 19, 2014, at 11:06 AM, Zachary Turner <ztur...@google.com> wrote:
>
> Definitely agree with you on this. I have no plans to go fixup old code, and
> I don't think others should either. And if we see a change go through that
> does attempt to fix up old code, we should block it.
>
> That said, I'm working on a clang-format file that will automate this
> formatting for us (or at least, for me, should nobody else choose to use it),
> and I plan to run it against all my changelists before submitting them. Note
> that this only reformats lines that have already been touched by the CL, so
> there's no risk of formatting-only changes making it in.
>
>
> On Tue, Aug 19, 2014 at 11:00 AM, Sean Callanan <scalla...@apple.com> wrote:
> One point about this discussion, by the way.
>
> While I support adherence to a consistent style for new/changed code, this
> should in no way be taken as support for going through and fixing
> indentation/style on old code.
> We have internal branches that become hell to merge when e.g. spacing has
> been altered subtly, or brace depth is changed…
> If we all do our part to clean the parts we’re touching, then I think that
> will be enough to keep LLDB clean.
>
> Sean
>
>> On Aug 19, 2014, at 10:16 AM, Zachary Turner <ztur...@google.com> wrote:
>>
>> I brought this up in a thread on lldb-commits, but since it is of more
>> general interest, I want to make a thread here as well.
>>
>> Can we have clear direction on LLDB coding style? Ideally in the form of an
>> update to lldb.llvm.org, but as that might require a little more effort,
>> even some details in a response to this thread would be a help. Some things
>> I've deduced from looking at the code, and other things I'm not so sure
>> about, because of inconsistencies in the code or just no clear rule.
>>
>> Indentation width: 4
>> Column limit: 140 (does this apply to comments too? Most
>> function-declaration comments seem to wrap at 80)
>> Brace style: Allman
>> if (foo)
>> {
>> // code here
>> }
>>
>> Break after function return type: Always, only on declarations, only on
>> definitions, only in headers, or never?
>>
>> Space before function parentheses: When?
>>
>> Indent case labels inside switch: A or B below?
>> switch (foo)
>> {
>> case A:
>> case B:
>> }
>>
>> Indent braces inside of a case: A or B below?
>> switch (foo)
>> {
>> case A:
>> {
>> }
>> case B:
>> {
>> }
>> }
>>
>> Any other rules I should be cognizant of?
>> _______________________________________________
>> 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
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
