-
Notifications
You must be signed in to change notification settings - Fork 1
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 Style #45
Comments
About whitespaces between pointer: |
Fun fact (not an argument, neither for nor against introducing a style guide): |
And the google style guide should accept both So I think this whitespace discussion is really unnecessary. But an overall coding style is useful.
or or And all the other things ... |
As before I'm sorry for opening the topic about white-spaces between pointer. I was far to strict to comment this and there is no right or wrong in this question. I will vote for the Google C++ Style Guide 👍 . Its well defined, modern and compact. |
But you mentioned it again. :D Yeah I also think the Google C++ Style is a good option. Maybe there is something like Beautify from JS ... That will be really hard for me, to not open the curly bracket in a new line.
|
I'll have a look at the google-style-guide later. But on a first glance there are already some things that bother me... 😅
I know the reason, but come on! Today, on widescreeen monitors, 80 is really not much :D I think I currently use 100 or so. ^^
Maybe my eyes are just too weak, but I really prefer 4 spaces. 🤓 Just to mention two obvious things. More on that later. :) |
I like 2 spaces. I think that is really enough and the code will not move out of the screen so fast. I agree with the 80 characters. But we need to provide compatibility with the code of the 60th! :D |
If your code becomes so deeply nested that your 4-space-indentation starts to create conflicts with the 100-(:wink:)-chars-per-line-limit, you should really reconsider your software design on a different level. :D |
Yeah 100 seem to be okay, but 80 and OOP? |
A style guide is more a recommendation than a law. And I know a guy who always split the code to the left and right side of his monitor ;-) But the limit protect you form 1 line complex functions or large 1 line if conditions or overall to long conditions. I wouldn't pay to match attention of 80 or 100 how long its not to long. Sometime with OOP and Namespaces it could be difficult to hold the limit. |
But if we say "we use the google style guide, but with the following exceptions: [...]" everything gets really messed up. No more automatic linter/tidy, and a real pita overall. Hey, I often split my editor into all 4 quadrants of my monitor... ^^ So you wouldn't want to say "fixed limit: <N> chars per line", but rather "be reasonable. Don't make your lines way too long."? We don't need a style-guide for that. 😉 |
To push this topic a bit. |
This would be one steps towards the "how to enforce/apply the style-guide", but we still didn't find a common base on "what should be enforced". See my previous comment: If we cannot explicitely say "that's what it must look like!", but rather say "We don't care too much, just be reasonable", there's no way to encode the latter in a style-guide / formatting options. |
I would perform to find a common coding style for sempr to have clear and readable code.
In most cases a clear style also helps the developer and reviewer to avoid bug.
Some example coding style:
The text was updated successfully, but these errors were encountered: