But some times it does not make sense - my biggest beef is the 80 char per line limit which seems to severely decrease readability if you use descriptive variable names… I have seen 120 char lines broken over 4 lines with unhelpful indentation which obfuscates the flow of the program. IOW breaking a 90 char line into two might make sense if there is a logical breakpoint; otherwise let the flow of the code determine line breaks within the limit of modern monitors.

I once worked on a large Python project with over 200,000 lines of code built over a period of five years with up to 20 programers at any time which had no coding standards. When I had to work on a piece of code I never had a problem with reading the code.

My only coding standard is to write readable code.

“then I use camelCase method names”
Wouldn’t that be half-camelCase (camel case comes from formula notation and so all first letters are caps, NaCl, etc.)?

Now that said, there’s no reason to say that absolutely all code has to follow the default style standard. Obviously coders have their own idiosyncratic style preferences and there’s always going to be some difference in how one person writes code versus how another person would. Personally I’m a fan of pretty printing systems that enforce a particular style and can be used to export code in any arbitrary style, although that generally works better in a setting where one IDE is dominantly used across the whole community. Overall I think as someone with a quirky coding style it just makes sense to acknowledge that your style might be “wrong” in terms of the standard, but that you like the “wrong” way better. For example I like viewing code on a big screen with a tiny font, so a width of more than the standard in most languages works better for me personally, but it’s understandable that doing that makes it harder for other coders to read and work with my code if I leave it like that.

I think there are excellent lexical reasons to “function()” as a representation of the calling mechanism that Python uses, and I think it profoundly affects code readability.

When I saw that you “function ()”, I thought, “Yup, I bet this guy gets a lot of backlash for not being PEP8 compliant, he’s picked a particularly ugly personal style for Python.”

My personal Python style definitely diverges from PEP8, I use 119 columns instead of 79, I wrap expressions before the symbol rather than after the symbol–like in standard math style, the next line starts with + instead of the previous line ending with +. But I’ve never gotten more than a shrug or a polite question about it.

I think what you might be getting is the “PEP8 as the first and last factual argument for code style in Python” effect in the Python community when it comes to talking about the merits of code style. Maybe instead of thinking about those complaints as “I’m a stickler for doctrine”, maybe those complaints are actually “I don’t like your personal code style.”

(Of course, of course, of course, you can code your own projects in any way you’d like. But maybe it’s not a matter of personal freedom, maybe it’s just that you’ve picked an unpopular style. :) )

- Attention to detail
- Familiarity with the Python ecosystem

Basically, it tells me the author has the discipline to follow a style guide (either naturally or enforced via external tools) and that they’ve been using Python long enough to know about it in the first place.

Now, does the lack of PEP8 inform the inverse? In reality, of course not. Twisted uses CamelCase because it predates PEP8 and Glyph eats puppies, for instance. Maybe your attention to detail is spent on your own personal style guide. I don’t know, nor am I arrogant enough to think I do. However, there are only so many hours in the day and countless third-party software projects; I’ve got to employ stereotypes as a time-saving measure to some extent.

All things being equal, if software violates PEP8 in really flagrant ways (like using two spaces instead of four), that represents a cognitive load to me (however small) and my stereotypes indicate the author may be less experienced in Python than I’d like for a third-party package. This has held true more often than not, so I stick with it. If the author’s software provides something I can’t find anywhere else, I’ll reluctantly give it a more thorough read. If not, I’ll just choose another package.

Personally, I aim for PEP8-like. I follow the arbitrary naming conventions (because you need a convention and PEP8 seems as good as any) but I don’t limit line length, I don’t make my docstrings so spacious, etc. But anyone who can’t work with my code because it doesn’t precisely fit some document… the problem lies with their adaptability.