Message ID | 1323178776-12305-2-git-send-email-thierry.reding@avionic-design.de (mailing list archive) |
---|---|
State | Accepted, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1RXvFL-0004JI-UL; Tue, 06 Dec 2011 14:39:48 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-3) with esmtp id 1RXvFL-000295-E1; Tue, 06 Dec 2011 14:39:47 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933369Ab1LFNjl (ORCPT <rfc822;hunold@linuxtv.org> + 4 others); Tue, 6 Dec 2011 08:39:41 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:55489 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933363Ab1LFNjk (ORCPT <rfc822; linux-media@vger.kernel.org>); Tue, 6 Dec 2011 08:39:40 -0500 Received: from benhur.adnet.avionic-design.de (p548E075F.dip0.t-ipconnect.de [84.142.7.95]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M8mxE-1RdS5u2WJY-00CZIZ; Tue, 06 Dec 2011 14:39:38 +0100 Received: from mailbox.adnet.avionic-design.de (add-virt-zarafa.adnet.avionic-design.de [172.20.129.9]) by benhur.adnet.avionic-design.de (Postfix) with ESMTP id 2B2D42C4122; Tue, 6 Dec 2011 14:39:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailbox.adnet.avionic-design.de (Postfix) with ESMTP id 25F962A28159; Tue, 6 Dec 2011 14:39:38 +0100 (CET) X-Virus-Scanned: amavisd-new at avionic-design.de Received: from mailbox.adnet.avionic-design.de ([127.0.0.1]) by localhost (mailbox.avionic-design.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLjBjlIUdPq3; Tue, 6 Dec 2011 14:39:37 +0100 (CET) Received: from localhost (avionic-0098.adnet.avionic-design.de [172.20.31.233]) (Authenticated sender: thierry.reding) by mailbox.adnet.avionic-design.de (Postfix) with ESMTPA id 4E9722A2818D; Tue, 6 Dec 2011 14:39:37 +0100 (CET) From: Thierry Reding <thierry.reding@avionic-design.de> To: linux-media@vger.kernel.org Cc: mchehab@redhat.com, Stefan Ringel <linuxtv@stefanringel.de> Subject: [PATCH 2/2] [media] tm6000: Fix bad indentation. Date: Tue, 6 Dec 2011 14:39:36 +0100 Message-Id: <1323178776-12305-2-git-send-email-thierry.reding@avionic-design.de> X-Mailer: git-send-email 1.7.8 In-Reply-To: <1323178776-12305-1-git-send-email-thierry.reding@avionic-design.de> References: <1322509580-14460-1-git-send-email-linuxtv@stefanringel.de> <1323178776-12305-1-git-send-email-thierry.reding@avionic-design.de> X-Provags-ID: V02:K0:I386r8RcKm2Qr+VJGdToIUJJbwgLMRq32oCudhd5fYN usBawM5zAzhggraJc6fk/Ns1c39HFGLjZlyCkOh6OZGUCtebcR y48sRwRVzMocAqv8r3r5ItdqOs76IRKJb7Dx4RwbCaWXsQkVyz VzoAJq6ZjtM3MWaW8VPBm+7MjGbH3t4qQSd6qgVW9IfkVcEomr JA6c0mZCJqHPB5cupd0FR0GAXE7mL3nfeVAmKzN0nU6NHmvdSE 22g5q3syE9+IERDMjbXl9sSwSn687ijtDAz9BNlp4c3dzVlza7 eQB8jbdMXb2BaHzEBHLq/1XVyl7zaza91BFo2RDeOVt/XBVZ/s UCV7m7d90TY7/PhThtJkW3s2zoYZo0A3SjwEivBRdb1K4PRIWE OQ+7CHZTjAicLQ9PogPfRBA/ifbXMCu24QhDwE3h0vI/oItQbE Fk+NR Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.6.133314 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS ' X-LSpam-Score: -6.9 (------) X-LSpam-Report: No, score=-6.9 required=5.0 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5 autolearn=ham |
Commit Message
Thierry Reding
Dec. 6, 2011, 1:39 p.m. UTC
Function parameters on subsequent lines should never be aligned with the
function name but rather be indented.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
drivers/media/video/tm6000/tm6000-video.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
Comments
That question is related to that kind of indentation generally, not only that patch. On 12/06/2011 03:39 PM, Thierry Reding wrote: > Function parameters on subsequent lines should never be aligned with the > function name but rather be indented. [...] > usb_set_interface(dev->udev, > - dev->isoc_in.bInterfaceNumber, > - 0); > + dev->isoc_in.bInterfaceNumber, 0); Which kind of indentation should be used when function params are slitted to multiple lines? In that case two tabs are used (related to function indentation). example: ret= function(param1, param2); Other generally used is only one tab (related to function indentation). example: ret= function(param1, param2); And last generally used is multiple tabs + spaces until same location where first param is meet (related to function indentation). I see that bad since use of tabs, with only spaces I see it fine. And this many times leads situation param level are actually different whilst originally idea was to put those same level. example: ret= function(param1, param2); regards Antti
* Antti Palosaari wrote: > That question is related to that kind of indentation generally, not > only that patch. > > On 12/06/2011 03:39 PM, Thierry Reding wrote: > >Function parameters on subsequent lines should never be aligned with the > >function name but rather be indented. > [...] > > usb_set_interface(dev->udev, > >- dev->isoc_in.bInterfaceNumber, > >- 0); > >+ dev->isoc_in.bInterfaceNumber, 0); > > Which kind of indentation should be used when function params are > slitted to multiple lines? I don't think this is documented anywhere and there are no hard rules with regard to this. I guess anything is fine as long as it is indented at all. > In that case two tabs are used (related to function indentation). > example: > ret= function(param1, > param2); I usually use that because it is my text editor's default. > Other generally used is only one tab (related to function indentation). > example: > ret= function(param1, > param2); I think that's okay as well. > And last generally used is multiple tabs + spaces until same > location where first param is meet (related to function > indentation). I see that bad since use of tabs, with only spaces I > see it fine. And this many times leads situation param level are > actually different whilst originally idea was to put those same > level. > example: > ret= function(param1, > param2); Whether this works or not always depends on the tab-width. I think most variations are okay here. Some people like to align them, other people don't. Thierry
On 06-12-2011 12:13, Thierry Reding wrote: > * Antti Palosaari wrote: >> That question is related to that kind of indentation generally, not >> only that patch. >> >> On 12/06/2011 03:39 PM, Thierry Reding wrote: >>> Function parameters on subsequent lines should never be aligned with the >>> function name but rather be indented. >> [...] >>> usb_set_interface(dev->udev, >>> - dev->isoc_in.bInterfaceNumber, >>> - 0); >>> + dev->isoc_in.bInterfaceNumber, 0); >> >> Which kind of indentation should be used when function params are >> slitted to multiple lines? Documentation/CodingStyle currently says: Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them. So, it should be: "substantially to the right" whatever this means. > I don't think this is documented anywhere and there are no hard rules with > regard to this. I guess anything is fine as long as it is indented at all. > >> In that case two tabs are used (related to function indentation). >> example: >> ret= function(param1, >> param2); > > I usually use that because it is my text editor's default. > >> Other generally used is only one tab (related to function indentation). >> example: >> ret= function(param1, >> param2); > > I think that's okay as well. One tab can hardly be interpreted as "substantially to the right". > >> And last generally used is multiple tabs + spaces until same >> location where first param is meet (related to function >> indentation). I see that bad since use of tabs, with only spaces I >> see it fine. And this many times leads situation param level are >> actually different whilst originally idea was to put those same >> level. >> example: >> ret= function(param1, >> param2); In practice, this is the most commonly used way, from what I noticed, not only at drivers/media. A good place to look for commonly used CodingStyle are the most used headers at include/linux. As far as I noticed, they all use this style. > > Whether this works or not always depends on the tab-width. I think most > variations are okay here. Some people like to align them, other people > don't. Tab width is always 8, according with the CodingStyle: "Tabs are 8 characters, and thus indentations are also 8 characters." Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/06/2011 10:58 PM, Mauro Carvalho Chehab wrote: > On 06-12-2011 12:13, Thierry Reding wrote: >> * Antti Palosaari wrote: >>> That question is related to that kind of indentation generally, not >>> only that patch. >>> >>> On 12/06/2011 03:39 PM, Thierry Reding wrote: >>>> Function parameters on subsequent lines should never be aligned with >>>> the >>>> function name but rather be indented. >>> [...] >>>> usb_set_interface(dev->udev, >>>> - dev->isoc_in.bInterfaceNumber, >>>> - 0); >>>> + dev->isoc_in.bInterfaceNumber, 0); >>> >>> Which kind of indentation should be used when function params are >>> slitted to multiple lines? > > Documentation/CodingStyle currently says: > > Statements longer than 80 columns will be broken into sensible chunks, > unless > exceeding 80 columns significantly increases readability and does not hide > information. Descendants are always substantially shorter than the > parent and > are placed substantially to the right. The same applies to function headers > with a long argument list. However, never break user-visible strings > such as > printk messages, because that breaks the ability to grep for them. > > So, it should be: "substantially to the right" whatever this means. > >> I don't think this is documented anywhere and there are no hard rules >> with >> regard to this. I guess anything is fine as long as it is indented at >> all. >> >>> In that case two tabs are used (related to function indentation). >>> example: >>> ret= function(param1, >>> param2); >> >> I usually use that because it is my text editor's default. >> >>> Other generally used is only one tab (related to function indentation). >>> example: >>> ret= function(param1, >>> param2); >> >> I think that's okay as well. > > One tab can hardly be interpreted as "substantially to the right". > >> >>> And last generally used is multiple tabs + spaces until same >>> location where first param is meet (related to function >>> indentation). I see that bad since use of tabs, with only spaces I >>> see it fine. And this many times leads situation param level are >>> actually different whilst originally idea was to put those same >>> level. >>> example: >>> ret= function(param1, >>> param2); > > In practice, this is the most commonly used way, from what I noticed, > not only > at drivers/media. A good place to look for commonly used CodingStyle are > the > most used headers at include/linux. As far as I noticed, they all use this > style. Yes, but it is not correct according to CodingStyle if you use spaces even when mixing with tabs. Correct seems to be intend it adding only tabs, as many as possible, still not to exceed 80 char line len limit. >> Whether this works or not always depends on the tab-width. I think most >> variations are okay here. Some people like to align them, other people >> don't. > > Tab width is always 8, according with the CodingStyle: > > "Tabs are 8 characters, and thus indentations are also 8 characters." > > Regards, > Mauro >
On 06-12-2011 19:03, Antti Palosaari wrote: > On 12/06/2011 10:58 PM, Mauro Carvalho Chehab wrote: >> On 06-12-2011 12:13, Thierry Reding wrote: >>> * Antti Palosaari wrote: >>>> That question is related to that kind of indentation generally, not >>>> only that patch. >>>> >>>> On 12/06/2011 03:39 PM, Thierry Reding wrote: >>>>> Function parameters on subsequent lines should never be aligned with >>>>> the >>>>> function name but rather be indented. >>>> [...] >>>>> usb_set_interface(dev->udev, >>>>> - dev->isoc_in.bInterfaceNumber, >>>>> - 0); >>>>> + dev->isoc_in.bInterfaceNumber, 0); >>>> >>>> Which kind of indentation should be used when function params are >>>> slitted to multiple lines? >> >> Documentation/CodingStyle currently says: >> >> Statements longer than 80 columns will be broken into sensible chunks, >> unless >> exceeding 80 columns significantly increases readability and does not hide >> information. Descendants are always substantially shorter than the >> parent and >> are placed substantially to the right. The same applies to function headers >> with a long argument list. However, never break user-visible strings >> such as >> printk messages, because that breaks the ability to grep for them. >> >> So, it should be: "substantially to the right" whatever this means. >> >>> I don't think this is documented anywhere and there are no hard rules >>> with >>> regard to this. I guess anything is fine as long as it is indented at >>> all. >>> >>>> In that case two tabs are used (related to function indentation). >>>> example: >>>> ret= function(param1, >>>> param2); >>> >>> I usually use that because it is my text editor's default. >>> >>>> Other generally used is only one tab (related to function indentation). >>>> example: >>>> ret= function(param1, >>>> param2); >>> >>> I think that's okay as well. >> >> One tab can hardly be interpreted as "substantially to the right". >> >>> >>>> And last generally used is multiple tabs + spaces until same >>>> location where first param is meet (related to function >>>> indentation). I see that bad since use of tabs, with only spaces I >>>> see it fine. And this many times leads situation param level are >>>> actually different whilst originally idea was to put those same >>>> level. >>>> example: >>>> ret= function(param1, >>>> param2); >> >> In practice, this is the most commonly used way, from what I noticed, >> not only >> at drivers/media. A good place to look for commonly used CodingStyle are >> the >> most used headers at include/linux. As far as I noticed, they all use this >> style. > > Yes, but it is not correct according to CodingStyle if you use spaces even when mixing with tabs. > > Correct seems to be intend it adding only tabs, as many as possible, still not to exceed 80 char line len limit. This is not indentation, it is long line breaking. There's nothing there saying that white spaces are not allowed on line breaks, nor checkpatch complains about it. So, it seems to be the better way for doing it, although CodingStyle doesn't enforce it. > > >>> Whether this works or not always depends on the tab-width. I think most >>> variations are okay here. Some people like to align them, other people >>> don't. >> >> Tab width is always 8, according with the CodingStyle: >> >> "Tabs are 8 characters, and thus indentations are also 8 characters." >> >> Regards, >> Mauro >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/video/tm6000/tm6000-video.c b/drivers/media/video/tm6000/tm6000-video.c index 87eb909..a15fd9d 100644 --- a/drivers/media/video/tm6000/tm6000-video.c +++ b/drivers/media/video/tm6000/tm6000-video.c @@ -1649,12 +1649,10 @@ static int tm6000_release(struct file *file) if (dev->int_in.endp) usb_set_interface(dev->udev, - dev->isoc_in.bInterfaceNumber, - 2); + dev->isoc_in.bInterfaceNumber, 2); else usb_set_interface(dev->udev, - dev->isoc_in.bInterfaceNumber, - 0); + dev->isoc_in.bInterfaceNumber, 0); /* Start interrupt USB pipe */ tm6000_ir_int_start(dev);