On 10/1/20 4:45 am, Gedare Bloom wrote: > On Wed, Jan 8, 2020 at 11:51 PM Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> >> On 08/01/2020 19:31, Gedare Bloom wrote: >>>> >>>> I agree completely on the proposed approach with Python tools. >>>> >>> Yes. Reading it I'm actually reminded about Google's approach toward >>> Python which includes many of the elements mentioned. Although their >>> guide is probably more comprehensive and verbose that what we need, it >>> might be a useful reference for developing a set of guidelines >>> suitable for Python code in RTEMS (mainly, rtems-tools). Here is a >>> link: >>> http://google.github.io/styleguide/pyguide.html >>> >>> I think most of the existing style has been determined and driving by >>> Chris Johns. So I would also give him some credit to develop/approve >>> how we plan to use Python at a project level. (**Hands Chris an "RTEMS >>> Python Maintainer" hat**);) >> >> I think the Google guide would be a good start. We can always add >> project-specific exceptions/clarifications if necessary. My aim is to >> use it for new code, e.g. code produced for the pre-qualification >> activity. For the code format I strongly want to use a tool for this. I >> don't want to spend review time on code formatting issues. >> >> Using standard guidelines makes the RTEMS Project more attractive for >> new contributors and GSoC students. I think it increases your job >> opportunities if you can refer to a successful GSoC project and it shows >> that you used standard engineering practices in the project. This is >> usually not something a university education includes. >> > OK, both points make sense. I'd be happy with the Google guide, I hope > Chris will comment when he can.
Sorry about the erratic access. I have been knee deep in painting and flooring this summer as I avoid any smoke from the fires we are having. I am fine with using a standard guide however we need to review it and to make sure it fits. As an example the C++ guide from Google had some good points as well as some parts I did not think offered any value but did create a certain level of pain. We should also consider capturing the guide as a public one belonging to someone else can and will change and that effects us. I am not sure how we could do this. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel