[OE-core] Yocto style guide change proposal

[Chris Larson]

On Fri, Jul 20, 2012 at 7:12 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Fri, 2012-07-20 at 06:57 -0700, Chris Larson wrote:
>> On Fri, Jul 20, 2012 at 6:56 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > On Fri, 2012-07-20 at 11:32 +0200, Martin Jansa wrote:
>> >> Now we have horrible mixture of whitespaces (tabs and space) only in
>> >> recipe files, because yocto style guide recommends tabs in shell
>> >> functions. So if recipe has e.g. do_install_append as well as
>> >> populate_packages_prepend (not so uncommon combination as tabs fixing
>> >> patches show), then according to yocto style guide it should look like
>> >> this:
>> >>
>> >> do_install_append() {
>> >>       foo
>> >> }
>> >> python populate_packages_prepend () {
>> >>     libdir = bb.data.expand('${libdir}', d)
>> >>     do_split_packages(d, libdir, '^lib(.*)\.so\.*', 'lib%s', 'ORC %s library', extra_depends='', allow_links=True)
>> >> }
>> >>
>> >> especially with default tab width 8 spaces it's ugly and because it
>> >> is inconsistent, many devs used spaces in shell functions too. Now when
>> >> someone accidentaly use tab also in python function it will show warning
>> >> or fail to parse. Some devs are using mix of tabs and spaces even on the
>> >> same line (e.g. to indent SRC_URI multiline entries).
>> >
>> > We've said tabs for shell functions for *years*. I'm sure if I were to
>> > look at the mailing list archives, that would be clear.
>> >
>> > In summary, I agree we need to make the style guides consistent and have
>> > one version of them. I disagree with spaces for everything though,m
>> > particularly as we have said to use tabs for as long and many of the
>> > recipes do this (certainly more than use spaces).
>>
>> I don't think history is a particularly good reason to keep our
>> metadata inconsistent, especially with bitbake becoming picky about
>> it.
>
> I don't see it as inconsistent. I think python needed some special
> handling since the language itself uses whitespace for structure and
> we're now following standard python practise and have a way to ensure
> some kinds of bugs don't creep in in future. It was already the agreed
> convention, it just wasn't getting well followed, or we had some issues
> migrating old mixed code to any one format without enforcing one.


If you don't see two different types of indentation in one file as
inconsistent, I think you need to look up consistency in a dictionary.
-- 
Christopher Larson