[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] USB virt 2.6 split driver patch series
On 11/22/05, harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2005-11-21 at 23:41 +0900, NAHieu wrote: > > On 11/21/05, harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > On Mon, 2005-11-21 at 14:49 +0100, Vincent Hanquez wrote: > > > > On Mon, Nov 21, 2005 at 01:18:24PM +0000, harry wrote: > > > > > o - I've reformatted all the code to the kernel coding style using > > > > > Lindent and not attempted to improve it after that. Some of the > > > > > formatting needs to be improved. > > > > > > > > some ? this is totally _not_ linux kernel coding style. > > > > please have a look at Documentation/CodingStyle and kill anonymous > > > > inline functions (braces in middle of functions). > > > > > > > > > > I have read Documentation/CodingStyle quite carefully and there is no > > > mention of using braces inside functions. I'm used to using braces to > > > define minimal scopes for local variables which makes the code easier to > > > read by minimising the number of variables you need to keep track of > > > when reading it and by declaring variables closer to where they are used > > > so it is easier to verify that they have been correctly initialised. > > > > > > Is this really banned? > > > > > > > I guess people complain because this is not a common practice. At > > least I never seen any code like that in the kernel. > > > > You could remove them because your functions are pretty short, and it > > easy enough to follow the code even if you put all the variables at > > the top of functions. > > Yes, I can do this if necessary. I like to put a trace point at the > start of functions before declaring varibles because some variable > initialisations result in calls to other functions and having the > tracepoint first gets the trace log in the correct order. The > alternative is to put the declaration first and then initialise after > the trace point. I'm not used to 8 space tabs either. The braces for > nested scope don't really work well with such big tabs. why you care about 8 space tabs? Just use tabs to align the code, and don't pay attention to how many spaces to a tab. If you think 8 spaces is too long, you could reconfigure your editor. For example I use vim as editor, and configure it to display 4 spaces for 1 tab (set shiftwidth=4), and the code looks much better. > > Lindent also messed up by putting the starting open brace for a number > of functions after the parameters rather than at the start of a new > line. There are also some problems from Lindent with parameter lists > being formatted in a confusing way. I need to go through and fix these > issues Beside spliting the code and send them to the list, could you send a whole in 1 file only? I want to patch it to my tree and give it a try. Downloading 17 files separately and patch them is tired ;-) Hieu _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |