Proposal for function/method naming standardization.

[tayler6000]

After seeing some of the programming style of @Input-BDF, I thought it would be a good idea to set a solid standard for function/method naming conventions. The documentation states the phrase "This [function] should not be called by the user." Over 20 times. This phrase will also be added quite a few more times in the recent updates in 1.6.0. In other programming languages, these are referred to as "private functions" and are usually not even accessible to someone using the API/library. Python does not have this functionality.

I propose that all function names should be in lowerCamelCase. For these purposes I define lowerCamelCase as the following:

No spaces or underscores.
The first word is all lowercase.
The first letter of each subsequent word is capitalized.
Acronyms and abbreviations maintain their standard capitalization.

If the function is a "private function", it should have a single underscore proceeding the function's name. For example, a private function with the desired name of "Hello World API" should be _helloWorldAPI, whereas a public function with the same name would be helloWorldAPI.

I propose that all class names should be in UpperCamelCase. For these purposes I define UpperCamelCase as the following:

No spaces or underscores.
The first letter of every word is capitalized.
Acronyms and abbreviations maintain their standard capitalization.

For example, Voice over Internet Protocol's standard acronym is VoIP, therefore the class for a Voice over Internet Protocol Call is called VoIPCall. If you wanted a class to have the name of "foo bar" it would be called FooBar.

Any thoughts would be appreciated!

[Input-BDF]

As stated in PEP8

Classnames should use CapWords convention as you stated UpperCamelCase. So I agree

Functions and variables should be lowercase, with words separated by underscores as necessary. I Like the idea of lowerCamelCase (I sometimes had the need to store functions in variables and call them. e.g. callbackfunction) so you will know it's a function.

Agree to single underscore proceeding function names: Function is private and should not be called outside of the class Double underscore proceeding function names: Function is protected and thus will/should not be overwritten in subclassable.

Single/Double underscore should also apply to class variables. So self._type is a private and only the class itself should change this. I often tend to also use this on local variables inside functions to remind myself to never change this during function runs.

However Codingstyle as i learned (and still learning) is the language of the team. At the end we should note everything down in contribution guidelines.

[tayler6000]

Also to quote PEP8, mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility. However, I do believe there is an importance to having standards across Python, after all, that is why PEP8 was created.

With that in mind, I believe we should stick with mixedCase/lowerCamelCase for 1.6.0, then afterward begin development of 2.0.0 where we will refactor all the code to match PEP8, since, though this was not always the case, pyVoIP uses the Semantic Versioning scheme Major.Minor.Patch. Which to quote Wikipedia Breaking changes are indicated by increasing the major number (high risk); new, non-breaking features increment the minor number (medium risk); and all other non-breaking changes increment the patch number (lowest risk). Refactoring all the code to match PEP8's naming conventions would definitely be a breaking change for anything using the API. Hence, we should not do it until 2.0.0.

I agree completely with your last point However Codingstyle as i learned (and still learning) is the language of the team. At the end we should note everything down in contribution guidelines. I opened this discussion with the intention of creating a contribution guidelines document, using the discussions had in the issue tracker to get a popular consensus.

[xyc0815]

If you want to get the code more python style than you also can change if self.callCallback != None: to if self.callCallback is not None:. the same for equals None if self.callCallback is None:

[tayler6000]

If you want to get the code more python style than you also can change if self.callCallback != None: to if self.callCallback is not None:. the same for equals None if self.callCallback is None:

Yes, this is something I've been planning on doing. Honestly, I'm just going to go through and add typing then Flake8 and MyPy everything.