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

[Thomas Huth]

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

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

 Thomas