All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Antti Palosaari <crope@iki.fi>
Cc: Thierry Reding <thierry.reding@avionic-design.de>,
	linux-media@vger.kernel.org,
	Stefan Ringel <linuxtv@stefanringel.de>
Subject: Re: [PATCH 2/2] [media] tm6000: Fix bad indentation.
Date: Wed, 07 Dec 2011 11:24:17 -0200	[thread overview]
Message-ID: <4EDF6901.3060409@redhat.com> (raw)
In-Reply-To: <4EDE8306.6000901@iki.fi>

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
>>
>
>

      reply	other threads:[~2011-12-07 13:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1322509580-14460-1-git-send-email-linuxtv@stefanringel.de>
2011-11-28 19:46 ` [PATCH 2/5] tm6000: bugfix register setting linuxtv
2011-11-28 19:46 ` [PATCH 3/5] tm6000: bugfix interrupt reset linuxtv
2011-12-05  7:21   ` Thierry Reding
2011-12-05 12:04     ` Mauro Carvalho Chehab
2011-12-05 15:38       ` Thierry Reding
2011-12-05 18:21         ` Mauro Carvalho Chehab
2011-12-05 20:02           ` Stefan Ringel
2011-12-05 20:16             ` Mauro Carvalho Chehab
2011-12-06  6:51               ` Thierry Reding
2011-12-06  8:12                 ` Thierry Reding
2011-12-06 12:25                   ` Mauro Carvalho Chehab
2011-12-06 13:05                     ` [PATCH] [media] tm6000: Fix fast USB access quirk Thierry Reding
2011-12-06 12:22                 ` [PATCH 3/5] tm6000: bugfix interrupt reset Mauro Carvalho Chehab
2011-11-28 19:46 ` [PATCH 4/5] tm6000: bugfix bulk transfer linuxtv
2011-11-28 19:46 ` [PATCH 5/5] tm6000: bugfix data check linuxtv
2011-11-30 17:21   ` Mauro Carvalho Chehab
2011-12-06 13:39 ` [PATCH 1/2] [media] tm6000: Fix check for interrupt endpoint Thierry Reding
2011-12-06 13:39   ` [PATCH 2/2] [media] tm6000: Fix bad indentation Thierry Reding
2011-12-06 13:58     ` Antti Palosaari
2011-12-06 14:13       ` Thierry Reding
2011-12-06 20:58         ` Mauro Carvalho Chehab
2011-12-06 21:03           ` Antti Palosaari
2011-12-07 13:24             ` Mauro Carvalho Chehab [this message]

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=4EDF6901.3060409@redhat.com \
    --to=mchehab@redhat.com \
    --cc=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=linuxtv@stefanringel.de \
    --cc=thierry.reding@avionic-design.de \
    /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.