On 2020-03-19 10:00 -0600, Gedare Bloom wrote:
> Thank you for kicking off this discussion. As with most style issues,
> a lot of personal preferences came out, but also some good reasoning
> was given on both sides.
Yeah, I know these conversations sometimes don't go well but everyone has been
On Wed, Mar 18, 2020 at 12:25 PM Amar Takhar wrote:
>
> The only one I would like to propose is the 80 character limit. This should
> be
> moved to something more reasonable such as 120.
>
> Code comments should remain below 80 however.
>
Thank you for kicking off this discussion. As with most
On Thu, Mar 19, 2020 at 1:25 AM Sebastian Huber
wrote:
>
> On 19/03/2020 07:31, Sebastian Huber wrote:
>
> > Hello Gedare,
> >
> > I am open for all exceptions provided
> >
> > * there is a well known tool available which can format the code
> > automatically with the exceptions,
> >
> > * the
t;> ESTEC
>> Keplerlaan 1, PO Box 299
>> NL-2200 AG Noordwijk, The Netherlands
>> thanassis.tsiod...@esa.int | www.esa.int
>> T +31 71 565 5332
>>
>>
>>
>> From:"Sebastian Huber"
>> To:"Christian Mauderer&qu
ystem, Software and Technology Department
>
> *ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands
> thanassis.tsiod...@esa.int | www.esa.int
> T +31 71 565 5332
>
>
>
> From:"Sebastian Huber"
> To: "Christian Mauderer" ,
Mauderer"
, devel@rtems.org
Date: 19/03/2020 07:24
Subject: Re: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools
Sent by:"devel"
On 19/03/2020 07:07, Christian Mauderer wrote:
I think we will have a really hard time to set up tools like formatters
or pylint to
On 19/03/2020 08:20, Chris Johns wrote:
It would be good if we can tag static dicts as discussed previously. If we
cannot I am ok to revisiting to design to remove them. I am sure this can be
done, it just takes time.
I think this is already covered by the examples in:
On 19/03/2020 07:31, Sebastian Huber wrote:
Hello Gedare,
I am open for all exceptions provided
* there is a well known tool available which can format the code
automatically with the exceptions,
* the static analyzer tools can be configured to give good results
with the exceptions, and
> On 19 Mar 2020, at 5:31 pm, Sebastian Huber
> wrote:
>
> Hello Gedare,
>
> I am open for all exceptions provided
>
> * there is a well known tool available which can format the code
> automatically with the exceptions,
>
> * the static analyzer tools can be configured to give good
Hello Gedare,
I am open for all exceptions provided
* there is a well known tool available which can format the code
automatically with the exceptions,
* the static analyzer tools can be configured to give good results with
the exceptions, and
* the exceptions are a best practice in a
On 19/03/2020 07:07, Christian Mauderer wrote:
I think we will have a really hard time to set up tools like formatters
or pylint to check and use these rules. I think setting a line length to
120 should be easy to possible for nearly any tool. But I expect that
setting it to 120 for code and 80
Hello Chris and Amar,
On 19/03/2020 04:01, Chris Johns wrote:
> On 19/3/20 7:06 am, Christian Mauderer wrote:
>> Hello Amar,
>>
>> On 18/03/2020 19:24, Amar Takhar wrote:
>>> The only one I would like to propose is the 80 character limit. This
>>> should be
>>> moved to something more
On 19/3/20 7:06 am, Christian Mauderer wrote:
> Hello Amar,
>
> On 18/03/2020 19:24, Amar Takhar wrote:
>> The only one I would like to propose is the 80 character limit. This should
>> be
>> moved to something more reasonable such as 120.
>>
>> Code comments should remain below 80 however.
>>
Hello Amar,
On 18/03/2020 19:24, Amar Takhar wrote:
> The only one I would like to propose is the 80 character limit. This should
> be
> moved to something more reasonable such as 120.
>
> Code comments should remain below 80 however.
>
I'm not a big fan of long lines (reason further below)
The only one I would like to propose is the 80 character limit. This should be
moved to something more reasonable such as 120.
Code comments should remain below 80 however.
Python itself has not followed this rule for a long time you can see many lines
over 80 in the Python source itself.
Hello all,
Sebastian has proposed some Python development guidelines for the
SWEng book, which is great and I'm even going to steal some of his
words here. I want to open the discussion for comments and requests
for changes to one specific point: Python Coding Style. I'm
specifically interested
16 matches
Mail list logo
