On Wednesday, January 28, 2015 at 10:40:35 AM UTC-8, RjOllos wrote:
>
> On Wednesday, January 14, 2015 at 12:11:48 AM UTC-8, Remy Blank wrote:
>>
>> Ryan Ollos wrote on 2015-01-14 03:03:
>> > Over the past several months I've accumulated in my notes a few items
>> > that I would like to add to the coding guidelines (1). I'm seeking
>> > feedback on these changes before editing the wiki.
>> >
>> > - Use trailing underscore to avoid conflicts with built-in keywords.
>> > I've seen this practice sparingly in the codebase and it's actually
>> > suggested in PEP-0008, but we have many instances of variables such as
>> > "id", so I think it would be good to add this point to the CodingStyle
>> > document.
>>
>> The current practice is to use the trailing underscore when the name
>> would be a keyword, but not when it would shadow a built-in. In other
>> words, use it only when you have to. You would therefore write "with_"
>> or "if_" but "id" is fine, because it isn't a keyword.
>>
>> I would have a weak preference for keeping this. In particular, the id()
>> function is only rarely used, and "id" is a very common and useful
>> variable name.
>>
>> > - On the trunk (Python 2.6+) we can start using str.format() rather
>> > than the string interpolation operator. Should str.format() be
>> preferred?
>>
>> No opinion on this. I'm still using % in my code, because I don't see a
>> strong advantage for str.format(), but I'm fine with it.
>>
>> > - The brackets are unnecessary in Genshi template variable. My
>> > suggestions is that $var be preferred to ${var}
>>
>> Sounds good. You still have to use the ${} syntax for embedding
>> expressions (as opposed to simple variables).
>>
>> > - Generally I seem to prefer putting the properties / attributes
>> before
>> > methods in class definitions, but I tend to think that's something I
>> > picked-up from C++ and maybe shouldn't be a guideline.
>>
>> That's somewhat ill-defined, since you don't need to declare attributes.
>> I tend to prefer keeping things together that go together, so if a
>> property is related to some methods, I would define them together and
>> not necessarily move the property arbitrarily to the top. Especially
>> since properties often look a lot like methods if you write:
>>
>> @property
>> def my_property(self):
>> ...
>>
>> -- Remy
>>
>>
> Thank you for the feedback. I edited the CodingStyle guide in:
> http://trac.edgewall.org/wiki/TracDev/CodingStyle?version=25
>
I added one more addition this evening, and just posting here for
transparency in case anyone would like to comment on it.
trac.edgewall.org/wiki/TracDev/CodingStyle?action=diff&version=27
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to trac-dev+unsubscr...@googlegroups.com.
To post to this group, send email to trac-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.
