[SLOF] [PATCH v2 02/19] fix code style in byteorder.h

[Nikunj A Dadhania]

Thomas Huth <thuth at redhat.com> writes:

> On 22.01.2016 08:02, Alexey Kardashevskiy wrote:
>> On 01/22/2016 05:41 PM, Thomas Huth wrote:
>>> On 22.01.2016 04:47, Alexey Kardashevskiy wrote:
>>>> On 01/20/2016 11:32 PM, Thomas Huth wrote:
>>>>
>>>>> Maybe we should also introduce a proper CODING_STYLE document for SLOF
>>>>> that mandates how format functions? (pointing to the Linux kernel
>>>>> coding
>>>>> style document for C code should likely be enough, but some coding
>>>>> style
>>>>> for Forth code would be good, too)
>>>>
>>>> Like this?
>>>>
>>>>
>>>> [vpl2 slof]$ git diff
>>>> diff --git a/README b/README
>>>> index 7895045..d5b758d 100644
>>>> --- a/README
>>>> +++ b/README
>>>> @@ -12,7 +12,7 @@ Index
>>>>   2.4 Extending the Forth engine
>>>>   3.0 Limitations
>>>>   4.0 Submitting patches
>>>> -
>>>> +5.0 Coding style
>>>>
>>>>   1.0 Introduction to Slimline Open Firmware
>>>>   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> @@ -247,6 +247,14 @@ confirm that you certify the Developer Certificate
>>>> of Origin  Version 1.1,
>>>>   see [3] for details.
>>>>
>>>>
>>>> +5.0 Coding style
>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> +
>>>> +New C code submitted to SLOF should follow the coding style guidelines
>>>> +for the Linux kernel [4].
>> 
>>>
>>> Maybe add a sentence that the "uintXX_t" types should be used instead of
>>> the kernel "uXX" and "__uXX" types (e.g. uint32_t instead of u32) ...
>>> otherwise people might start to introduce these again ...
>> 
>> 
>> ===
>> ...with the following exceptions:
>> 
>> - in the event that you require a specific width, use a standard type
>> like int32_t, uint32_t, uint64_t, etc. Don't use Linux kernel internal
>> types like u32, __u32 or __le32.
>> ===
>> 
>> Copied from QEMU's HACKING.
>> 
>> 
>>>> +New forth code should use 3 space intents and no tabs.
>>>
>>> s/intent/indentation/
>>>
>>> Theoretically ACK since this was the style that we originally used in
>>> the SLOF sources and which is also used in the examples of IEEE 1275 (so
>>> you could refer to that spec here).
>>>
>>> Question is: Do we still want this? The 3 space indentation never really
>>> worked well - people are just not used to indent with 3 spaces, and some
>>> already configured their editor to use tabs (because of the C code), so
>>> result in new patches is really a mess most of the time.
>> 
>> Well, we do more and more in C than in forth so I do not expect very
>> much of new forth code anyway so I can live with 3 spaces. It is more up
>> to Nikunj actually :)

I do prefer eitther 4 spaces or a tab for newer forth code that we add.

>
> Ok, makes sense.
>
>>> Not sure how to improve this situation, though. Maybe new code should be
>>> indented with 4 spaces? Or simply with tabs, just like the C code?
>>> ... it's Friday, let's start some bike-shed painting discussion!
>> 
>> If you configure your editor to use tabs, then 4 spaces are as bad as 3
>> spaces anyway. May be it is time to learn how to configure different
>> tabstop for different file types in vim/emacs :)
>
> My editor (geany) has an option to determine the indentation type (space
> vs. tab) and indentation width automatically when opening a file, so I'm
> certainly fine with 3 tabs, too. But I think you should then also be
> more strict on the patches that you accept - there were quite a lot of
> spots that got indented with tabs and different width in the recent
> years, and that looks quite inconsistent when looking at the sources...

For C i tried to stick with kernel style for newer code. But Forth,
might have got messed up.

Regards
Nikunj