similar to: [LLVMdev] cosmetic changes to LLVM coding standards

Hi, I uploaded a patch for the "*Kind enum" rule to http://codereview.appspot.com/3402041 and attached it to this message too. Would you please take a look? Thanks, On Wed, Dec 1, 2010 at 9:19 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > Thanks, Chris and John.  Committed in r120689.  I'll try to add the > *Kind rule in a separate patch.  Cheers, > >

On Dec 1, 2010, at 9:32 PM, Zhanyong Wan (λx.x x) wrote: > Hi, > > I uploaded a patch for the "*Kind enum" rule to > > http://codereview.appspot.com/3402041 > > and attached it to this message too. Would you please take a look? Thanks, Applied, thanks! After applying it, I went through and restructured the section for readability:

On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > +llvmdev > > Thanks for the comments, Chris. > > On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: >> >>> Hi guys, >>> >>> Based on our discussion

On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > Hi Chris, > > I've uploaded a new patch to http://codereview.appspot.com/3264041. > It's also attached to this message. This patch looks great to me, please apply, thanks! > I think I've addressed all your comments, except "when in doubt, an > enum should be a 'Kind'". I don't

Thanks, Chris and John. Committed in r120689. I'll try to add the *Kind rule in a separate patch. Cheers, On Wed, Dec 1, 2010 at 5:18 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi Chris, >> >> I've uploaded a new patch to http://codereview.appspot.com/3264041. >> It's

Hi Chris, I've uploaded a new patch to http://codereview.appspot.com/3264041. It's also attached to this message. I think I've addressed all your comments, except "when in doubt, an enum should be a 'Kind'". I don't think I fully understand that point, and it strikes me as a bit ad hoc for the coding standards. Do we really want it? If you feel that's

+llvmdev Thanks for the comments, Chris. On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi guys, >> >> Based on our discussion last week, I put together a new coding style >> rule regarding the naming of types/functions/variables.  I've uploaded >>

On Tue, Nov 30, 2010 at 5:07 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: > >> Thanks for the comments, Chris!  Glad that we are making progress. >> >> I'll make most of the edits you suggested later today.  Before that, >> there are a couple of high-level points I'd like to go over

Hi Doug, While refactoring clang::FileManager to use llvm::sys::path, I had a need for a function to test whether a char is a path separator. I think it would be generally useful. Would you be able to review it? You can see http://codereview.appspot.com/4186045 or the attachment. Thanks, -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi, I enjoyed the new coding style in recent patches. Camel case makes it easy to pick a descriptive name. Starting functions and variables with lower cases reduces chances to conflict with a type name. 2010/11/23 Zhanyong Wan (λx.x x) <wan at google.com> > On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: > > +llvmdev > > >

Thanks for the comments, Chris! Glad that we are making progress. I'll make most of the edits you suggested later today. Before that, there are a couple of high-level points I'd like to go over with you. 1. I totally agree that the biggest benefit of a naming convention is uniform APIs. On the other hand, an inconsistent local naming style hurts the productivity of contributors and

Zhanyong Wan (λx.x x) wrote: > If possible, I'd prefer that all variable names have the same style. > I'm afraid that we'll end up with the current inconsistent style if > we > leave it to people to interpret whether a name is metasyntactic and > thus should be lower-case. > > Also, having both types and variables in StrictCamelCase increases > the > chance

On Tue, Nov 23, 2010 at 10:15 AM, Bo Persson <bop at gmb.dk> wrote: >  > > > ----- Original Message ----- > From: Chandler Carruth > To: Zhanyong Wan (λx.x x) > Cc: Argyrios Kyrtzidis ; clang-dev Developers > Sent: Tuesday, November 23, 2010 6:40 AM > Subject: Re: [cfe-dev] draft rule for naming types/functions/variables > On Mon, Nov 22, 2010 at 9:36 PM,

On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: > Thanks for the comments, Chris! Glad that we are making progress. > > I'll make most of the edits you suggested later today. Before that, > there are a couple of high-level points I'd like to go over with you. > > 1. I totally agree that the biggest benefit of a naming convention is > uniform APIs. On

On Sun, Nov 28, 2010 at 11:02 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> I enjoyed the new coding style in recent patches. Camel case makes it easy >> to pick a descriptive name. Starting functions and variables with lower >> cases reduces chances to conflict with a type name. > Honestly speaking, I don't. Especially in the cases when varname is

On Nov 29, 2010, at 11:07 AM, Zhanyong Wan (λx.x x) wrote: > C++ is such a complex language that no single naming convention will > be able to cover all cases. Therefore we aim at a reasonable default > that works for the majority of the cases. As Chris put at the > beginning of the coding standards, "no coding standards should be > regarded as absolute requirements to be

Hello Opus community, I'd like to ask you for advice and recommendations. WebRTC uses Opus, and I noticed https://webrtc-codereview.appspot.com/5549004 started referring to currently internal Opus headers. This is possible because for Chromium the Opus sources are just checked in, so any header can be #included. I detected this when trying to package Chromium for Linux distributions with

Here's a (more) proper patch for getting the tests to run on windows. With this only ~250 tests Unexpected Fail. I just need someone to make sure it doesn't break anything on other platforms. It feels kind of hacky, and I would appreciate any ideas on improvements. http://codereview.appspot.com/1657041/show - Michael Spencer

On 29 nov 2010 03:47 "Xu Zhongxing" <xuzhongxing at gmail.com> wrote: > Hi, > I enjoyed the new coding style in recent patches. Camel case makes it > easy to pick a descriptive name. Starting functions and variables with > lower cases reduces chances to conflict with a type name. On the other hand, having names that only differ in the case of a single character, is not

>> That makes four optional arguments to ExecutionEngine::create.  Do you >> mind if I go ahead and add an EngineBuilder? > > Please, thanks. This turned out to be somewhat involved and should probably be a separate patch. I started it, so I'll send it along later. The patch I'd like to submit now is attached and linked. http://codereview.appspot.com/90053/show Reid