Brock Pytlik wrote: > I'd like to suggest we update the pylintrc file we distribute to > actually mirror the standards we're using. The obvious change is to > switch the line length from 90 to 80, but I think we should make the > regex's for variables/function names/etc reflect the standards and stop > suppressing the warnings when something's wrong. We can decide if other > standards (max lines per module, max branches per function, etc...) are > things we care about or not (I tend to lean towards "no" in general, but > could be convinced otherwise). If we can't get pylint to enforce the 8 > spaces vs tab issue (something I'm unclear on at the moment) we can > write a small program to look for that problem as well. > > Once we agree on those standards, we take one pass through the code and > fix all these problems in one fell swoop. > > To make it less likely that more problems (on a large scale) will be > introduced, we can create "make lint" (or pylint, whatever) that will > automatically generate a lint report on the files you've touched (or > possibly all files, ideally this would be an option). The idea would be > that any code we put back would have 0 pylint errors (with exceptions > made for good reasons). Of course, it's up to each of us to decide what > a "good reason" is and to remeber to run it before doing the put back > (something I know I forget), but this would at least make it easier to > remember and follow. > > Since I'm the one writing this, I will volunteer to start the process, > modifying the pytlintrc, gathering opinions, thoughts etc..., if the > idea in general meats with approval. If someone else would like to > spearhead this process, please feel free. (In other words, this isn't my > baby and I'm happy to hand it off to someone if they feel strongly about > it.) > > So, if this something we all think is worth doing, say so and we can > start moving towards consensus on the standards we should be encode into > pylintrc (and also think about standards we can't encode there and how > we might automate the testing of those as well).
Good idea, thanks for doing this. To start the formating discussions, I'd really like to avoid all the escapes or '\' characters needed to handle our code and 8 space indents; have we considered using 4? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
