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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
