From: Dan Carpenter <dan.carpenter@oracle.com>
To: Markus Grabner <grabner@icg.tugraz.at>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
devel@driverdev.osuosl.org,
line6linux-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Daniel Mack <zonque@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 1/8] staging: line6: wrap >80 char lines in capture.c
Date: Fri, 16 Nov 2012 00:38:22 +0300 [thread overview]
Message-ID: <20121115213821.GK11566@mwanda> (raw)
In-Reply-To: <1602710.lBylyCQOHr@medialab>
On Thu, Nov 15, 2012 at 10:03:27PM +0100, Markus Grabner wrote:
> Am Mittwoch, 14. November 2012, 17:33:05 schrieb Dan Carpenter:
> > On Sun, Nov 11, 2012 at 01:24:39PM +0100, Stefan Hajnoczi wrote:
> > > Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
> > > ---
> > >
> > > drivers/staging/line6/capture.c | 13 ++++++++-----
> > > 1 file changed, 8 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/staging/line6/capture.c
> > > b/drivers/staging/line6/capture.c index c85c5b6..389c41f 100644
> > > --- a/drivers/staging/line6/capture.c
> > > +++ b/drivers/staging/line6/capture.c
> > > @@ -256,8 +256,8 @@ static void audio_in_callback(struct urb *urb)
> > >
> > > #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE
> > >
> > > if (!(line6pcm->flags & LINE6_BITS_PCM_IMPULSE))
> > >
> > > #endif
> > >
> > > - if (test_bit(LINE6_INDEX_PCM_ALSA_CAPTURE_STREAM, &line6pcm-
> >flags)
> > > - && (fsize > 0))
> > > + if (test_bit(LINE6_INDEX_PCM_ALSA_CAPTURE_STREAM,
> >
> > The reason this is hitting the 80 character limit is because
> > "LINE6_INDEX_PCM_ALSA_CAPTURE_STREAM" is 35 characters long. It
> > isn't even clear from the name what it holds. It's just a very crap
> > name.
> Please refer to the file pcm.h for a detailed documentation of this and
> similar names (in fact, the documentation explains the LINE6_BIT_PCM_* names
> instead, but I bevlieve the correspondence is obvious). It's hard to define a
> shorter name which is at the same time descriptive, consistent, and not to be
> confused with related names.
>
> Should such documentation be moved to a separate file (e.g.,
> "Documentation/sound/alsa/line6usb.txt")?
The documentation is pretty good actually and it belongs where it
is. But 35 characters is just tooooooooooooooooooooooooooooooooooo
long.
To me the word "INDEX_" is confusing because what are we indexing?
In this context it means the the variable is a bit flag. That was
obvious because we were calling test_bit().
I think we could drop the PCM_ as well, because why do we need that?
We could change the LINE6 to L6.
if (test_bit(L6_ALSA_CAPTURE_STREAM, &line6pcm - flags)
It fits!
regards,
dan carpenter
next prev parent reply other threads:[~2012-11-15 21:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-11 12:24 [PATCH 0/8] staging: line6: checkpatch.pl cleanups Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 1/8] staging: line6: wrap >80 char lines in capture.c Stefan Hajnoczi
2012-11-14 14:33 ` Dan Carpenter
2012-11-15 21:03 ` Markus Grabner
2012-11-15 21:38 ` Dan Carpenter [this message]
2012-11-15 22:12 ` Joe Perches
2012-11-15 23:43 ` Markus Grabner
2012-11-16 0:30 ` Joe Perches
2012-11-11 12:24 ` [PATCH 2/8] staging: line6: fix quoted string across lines in midibuf.c Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 3/8] staging: line6: shorten comment below 80 chars in pcm.c Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 4/8] staging: line6: drop trailing whitespace in pcm.h Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 5/8] staging: line6: wrap lines to 80 chars in playback.c Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 6/8] staging: line6: replace deprecated strict_strtol() in toneport.c Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 7/8] staging: line6: wrap lines to 80 chars in usbdefs.h Stefan Hajnoczi
2012-11-11 12:24 ` [PATCH 8/8] staging: line6: wrap comment to 80 chars in variax.c Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121115213821.GK11566@mwanda \
--to=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=grabner@icg.tugraz.at \
--cc=gregkh@linuxfoundation.org \
--cc=line6linux-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=stefanha@gmail.com \
--cc=zonque@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.