Firstly, I can't stress enough how much we need artwork. Concept sketches; pixel art; basically anything to get us moving.
Method Names and Instance Variables
Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.
Use one leading underscore only for non-public methods and instance variables.
mixedCase is allowed only in contexts where that's already the prevailing style
now the abbreviations and capitalizing is driving me nuts.
su for setup
pg for pygame
Surf for surface
also in pep8 it said method and instance variables should follow function rules.
self.instance_variable = 5 #I'm an instance variable
The example you have used here is referred to in the pep8 document as mixedCase, not CamelCase, and indeed mixedCase is highly discouraged in python.also python is moving away from camelCase.
pep8 wrote:CapitalizedWords (or CapWords, or CamelCase -- so named because of the bumpy look of its letters ). This is also sometimes known as StudlyCaps.
Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition.
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.
But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!
As long you guys agree on a consistant style for the project it will be ok
but i did find in pep8.
DrakeMagi wrote:how are you guys handle xrange, range difference ?
if sys.version_info == 2:
range = xrange
jkbbwr wrote:Have two separate master branches. py2 and py3
tag all subsequent branches as either py2-<branchname> or py3-<branchname>
keep releases separate. Mixing version logic gets complicated quickly. This also means you can test, deploy and release far easier than having mixed logic that works on all versions, and its more optimised, less instructions and less that can go wrong.
As for range or xrange, unless you need a list, always use xrange. Simple as.
Hey, do you guys still need art? Let me know what file-types and what kind of graphics you need, and I can whip something up.
Users browsing this forum: W3C [Linkcheck] and 2 guests