New coding style for new files?

[Joel Sherrill]

https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify

On Fri, Sep 11, 2020 at 11:46 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Fri, Sep 11, 2020 at 11:06 AM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>> >
>> > On 10/09/2020 17:32, Joel Sherrill wrote:
>> >
>> > >
>> > >
>> > > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom <gedare at rtems.org
>> > > <mailto:gedare at rtems.org>> wrote:
>> > >
>> > >     On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber
>> > >     <sebastian.huber at embedded-brains.de
>> > >     <mailto:sebastian.huber at embedded-brains.de>> wrote:
>> > >     >
>> > >     > Hello,
>> > >     >
>> > >     > I think we waste too much time to address coding style issues on
>> > >     newly
>> > >     > contributed code, for example GSoC. I don't know a source code
>> > >     > formatting tool which supports the RTEMS coding style and I
>> > >     think it is
>> > >     > not worth the time to write and maintain such a tool
>> > >     specifically for
>> > >     > RTEMS. Why don't we simply allow an alternative coding style
>> > >     which has a
>> > >     > good code formatter for new source files? I don't propose to
>> > >     reformat
>> > >     > the existing files.
>> > >     >
>> > >     > I would simply pick up one of the standard styles supported by
>> > >     > clang-format and declare it as an acceptable coding style for
>> RTEMS.
>> > >
>> > >
>> > > I am not willing to blanket accept another project's coding style.
>> > >
>> > > I am willing to accept a configuration for a tool that is close to our
>> > > style and
>> > > make compromises on specific points.
>> >
>> > We had a student to figure this out for clang-format some time ago:
>> >
>> > https://lists.rtems.org/pipermail/devel/2019-February/024912.html
>> >
>> > We could also have a look at uncrustify:
>> >
>> > https://github.com/uncrustify/uncrustify
>> >
>> > It seems to be still actively maintained on Github.
>> >
>> > >
>> > > I also think when doing this we should consider things that we do that
>> > > we have since learned safety standards don't like such as single
>> statement
>> > > if's without braces. I think we should have braces now.
>> > I think uncrustify had options to do this. I am not sure if clang-format
>> > can do this.
>> > >
>> > > This is best viewed as an opportunity to improve but comes with
>> changes
>> > > since I don't think any of us wants to add a few more configuration
>> > > options
>> > > to any formatter. Although if we get close, I can see adding those as
>> open
>> > > projects if someone is interested.
>> > Good, I think we should have a look at uncrustify. The RTEMS coding
>> > style is too exotic for clang-format.
>>
>> Let's start with uncrustify. The github looks solid with
>> cross-platform compatibility claims (*nix, Windows, OSX).
>>
>> I know that there was an RTEMS style script generated by Sebastian
>> some time ago. We had it on the wiki forever, but now it is a broken
>> link in the docs
>>
>> https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify
>>
>> from
>> https://docs.rtems.org/branches/master/eng/coding-conventions.html#tools
>>
>> So we'll need to revive that first, and iterate.
>>
>
> Amar has backups of the old wiki based on wikipedia and I think he can
> access it easily.
>
> --joel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200911/c1a49892/attachment.html>