On Thu, Sep 25, 2014 at 11:53:53AM -0500, Romer, Benjamin M wrote: > On Wed, 2014-09-24 at 19:34 +0300, Dan Carpenter wrote: > > On Wed, Sep 24, 2014 at 11:56:19AM -0400, Benjamin Romer wrote: > > > +struct periodic_work * > > > + visor_periodic_work_create(ulong jiffy_interval, > > > + struct workqueue_struct *workqueue, > > > + void (*workfunc)(void *), > > > + void *workfuncarg, > > > + const char *devnam); > > > > No. This isn't the right way to do it. The way the lines were broken > > up originally was fine. It's ok to pull the parameter declarations back > > to make it under the 80 character limit. > > Sorry, it was kind of an act of desperation to try and pass the strict > check for parenthesis alignment. I originally wanted to do it like this: > > struct periodic_work *visor_periodic_work_create(ulong jiffy_interval, > struct workqueue_struct *workqueue, > void (*workfunc)(void*), void *workfuncarg, > const char *devnam); That looks like an inpenetrable wall of text. I feel like it looks better to push the parameters in further. struct periodic_work *visor_periodic_work_create(ulong jiffy_interval, struct workqueue_struct *workqueue, void (*workfunc)(void*), void *workfuncarg, const char *devnam); But it doesn't really matter. Sometimes none of the options look wonderful. But the other format was just sort of unique and weird. > > But that generates the same parenthesis check message with --strict > turned on. Trying to align everything with the parenthesis was very > ugly, so I tried to save space by splitting the line at the return type. > > So should I just ignore the parenthesis warning for this one function? Yes. Ignore anything if you think it looks better that way. > I'm kind of confused about this particular check to be honest. In > Documentation/CodingStyle it says to never use spaces for indentation, > but there's no way to pass this check without using spaces, or getting > lucky and having things line up exactly on a tab. You can use spaces at the end to make things line up. This has become the standard in the past few years. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
