Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming conventions #227

Open
cgnitash opened this issue May 27, 2018 · 3 comments
Open

Naming conventions #227

cgnitash opened this issue May 27, 2018 · 3 comments

Comments

@cgnitash
Copy link
Collaborator

cgnitash commented May 27, 2018

Since the code base has been around a long time, there have been a number of naming conventions, and now it's all somewhat jumbled up.

Here's a proposal for fixing the naming conventions. We don't have to apply these changes to existing code in any hurry, but new code can follow the convention, making it much easier to read. The following should have the least impact;

Classes (Abstract and Concrete): CamelCase
SomeClass

Functions: Mixed-case
someFunction
(it might make sense to additionally have different naming conventions for virtual functions)

Variables: lowercase-with-underscores
some_variable

Member variables: lowercase-with-underscores and ending with an underscore
some_member_variable_

Thoughts?

@cliff-bohm
Copy link
Collaborator

cliff-bohm commented Jun 11, 2018

If we use this standard, will that mean that PLs will change?
i.e. does 'cullBelowPL' become 'cull_Below_PL'?

or 'cull_below_pl_'?

@JorySchossau
Copy link
Member

I suspect acronyms remain all caps, such as member variables: cull_below_PL_

@cgnitash cgnitash reopened this Jun 19, 2018
@VincentRagusa
Copy link
Collaborator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants