-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Coding conventions #1826
Comments
Alexandre, I think a good place to start is to help improve the wiki we have by making some edits and get some feedback. I would recommend you do this on your branch and then post here for feedback. @lukas-w has made most of the recent changes to our existing standards so I'd start with him. @diizy is good for feedback as well. -Tres |
The conventions have already been decided, they are listed on the coding conventions page. If something is not mentioned there, then it is up to each individual coder to decide. We don't need to be overly strict with the conventions because that'll just make things harder for everyone.
Static members are prefixed with s_ just like non-static members are prefixed with m_. This should be in conventions also.
It's undefined so up to each coder to decide. Space usage is encouraged for complex nested parentheses, but not mandatory anymore. |
@M374LX, this looks pretty good. I'm prpbably not the right person to approve this so I'll wait for more feedback. The one item I noticed is the use of |
We already have conventions and I don't see any reason to change them at the moment. |
Vesa, from what I can see Alexandre's article is based off of ours, but tries to clear up a few areas that aren't clearly defined. |
I agree with Vesa. Being too strict with the conventions and having too many rules just makes development harder for everyone. A good set of rules can be helpful in a large development team, which we don't have. In general, I'd say less is more. I'd be fine with dropping most of our rules, maybe even all of them, because I don't think they are of any great use. Developers who care about a good coding style will be able look at the codebase and will try to make their code fit in and make it readable without reading any guidelines. Developers who don't care won't even bother reading the
That's actually not suggested anywhere in our guidelines. ;) The paragraph you're probably referring to is about using |
Thanks for the feedback guys. @M374LX the feedback from these two is about the best we're probably going to get, so we may want to consider closing this out as wont-fix. -Tres |
Not a bad idea dropping most of the conventions, but the current conventions for naming (eg. uppercase initial for types, |
Honestly, I think a more important thing than syntactic conventions to agree upon are appropriate language subsets. For example, I tend to restrict myself to using the automatic memory management features of C++ (unique_ptr and the like) and avoid explicit Similarly, there are some one-time init functions that call |
As part of a pruning effort, this |
https://github.com/lmms/lmms/wiki/Coding-conventions
The project's coding conventions have clearly changed many times since it started, while older code has not been updated. Therefore, we need to decide the definitive conventions and avoid changing them again.
I have already made some pull requests to update the conventions on the code, but a better idea is to decide the definitive conventions before continuing the updates.
One topic not covered in the wiki page is the naming of static class members. A possibility is the "s_" prefix, as currently used in some parts of the code.
It seems that the conventions for spaces in parentheses have changed, but the new conventions are not covered. Also, it is not defined whether there should be a space between keywords (if, while, for, switch, ...) and the following opening parenthesis. Many projects use such space.
Nothing is said about indenting statements spanning multiple lines.
Some topics in the page show example code with outdated conventions, like the topic about infix operators showing an example with snake_case, rather than camelCase.
One thing I do not agree to is the usage of the "true" and "false" keywords when comparing Boolean values. Instead of "if (x == true)" and "if (x == false)", I suggest to change it to simply "if (x)" and "if (!x)".
The text was updated successfully, but these errors were encountered: