member variable names are not checked

[jauerb]

member variables are not checked for compliance with naming conventions No warnings are created for improperly named member variables like self.someVariable

[jauerb]

Is there a reason we would not want this?

A simple fix I found would be to add

elif target_type is ast.Attribute:
    yield assignment_target.attr

at the end of _extract_names

In which case these would get reported as N806, but not sure if this should be a different error code.

[5j9]

The problem is that if the member is part of another library's API, e.g. self.maxDiff = None in unittest module, then it leads to errors that are out of the control of your code-base.

[julienr]

I would like this as well.

@5j9 I understand your concern about this being possibly out of your control, but would it be possible to add this as an opt-in check ?

I tried the same solution as @jauerb on a relatively large codebase at my company and we have no out-of-our-control false positive, so adding this as an opt-in would be useful for us.

I started working on patch here, would be happy to make it opt-in if there is a way to do that.

[joseguerr]

We would also enjoy to this at our company.

[sigmavirus24]

It's possible to have this such that it's disabled by default. A template to follow is in https://github.com/PyCQA/pep8-naming/pull/157

[joseguerr]

Thanks for the help @sigmavirus24 , should I name it N819?

[sigmavirus24]

I generally think that the error codes should be better grouped (I didn't check this for N818). I'd suggest N820.

• N80* - is related to class, function, and function argument names
• N81* - was mostly related to changes in casing (until N818)
• N82* - would probably be best to start for method/property/attribute naming conventions on a class although this seems related to N815 and N816.