New coding style for new files?

[Joel Sherrill]

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/7e08ba05/attachment-0001.html>