Coding style about yuview HOT 9 CLOSED

I would suggest:

• Indentation 2 spaces (no Tabs - tabs just always look different depending on your IDE)
• Curly brackets. I Like

if (isAwesome) {
  i = i+2;
  i--;
}

• I also like the "no brackets for one if/else:

if (isAwesome)
  i = i+2;
else
  i--;

from yuview.

• I agree on 2 spaces per tab, so everyone should configure their IDE like that
• Use of Unix style LF and UTF-8 encoding for all source files
• I personally despise the Stroustrup / whatever style and like:

if (isAwesome)
{
  i = i+2;
  i--;
}

• No curly brackets for single clauses is ok

from yuview.

A common coding style would be nice. Guess there are some already defined
somewhere and we can just choose the one closest to what we are doing
anyway. But would be good to have a reference.
What about variables? We use the firstLetterOfWordCapitalScheme right? Also
most class variables are p_something. p for private?

On Wed, Nov 18, 2015 at 5:31 PM, Christian [email protected] wrote:

I would suggest:

• Indentation 2 spaces (no Tabs - tabs just always look different
  depending on your IDE)
• Curly brackets. I Like

if (isAwesome) {
i = i+2;
i--;
}

• I also like the "no brackets for one if/else:

if (isAwesome)
i = i+2;else
i--;

—
Reply to this email directly or view it on GitHub
#20 (comment).

from yuview.

Yes, some simplified variant of the Hungarian Notation (https://en.wikipedia.org/wiki/Hungarian_notation) would be nice, so i like bThatsABool, iThatsSomeInt, dFancyDouble, etc. (except for the iterators i,j,k,l which should always be ints ;-)) and if it is a member of a class, we need to decide on an indicator: m_bPrivateBool or p_bPrivateBool?

How about handling pointers?

from yuview.

Hungarian Notation looks nice. Shoud we also use it to mark the return
value of functions?

can we use either references or smart pointers? or are there cases where we
really need pure pointers ...
There are some smart pointers in qt and even c++11 has them too.

On Wed, Nov 18, 2015 at 6:44 PM, Max Blaeser [email protected]
wrote:

Yes, some simplified variant of the Hungarian Notation (
https://en.wikipedia.org/wiki/Hungarian_notation) would be nice, so i
like bThatsABool, iThatsSomeInt, dFancyDouble, etc. (except for the
iterators i,j,k,l which should always be ints ;-)) and if it is a member of
a class, we need to decide on an indicator: m_bPrivateBool oder
p_bPrivateBool?

How about handling pointers?

—
Reply to this email directly or view it on GitHub
#20 (comment).

from yuview.

Having a discussion on the coding style is a good sign for the overall status of the project. :-)

I think type-dependent prefixes are not needed with modern IDEs. Also, prefixing private variables is kind of outdated. I am voting against both.

IMHO, camel-casing would be more appropriate for a high level project. Snake-casing is typically found in low-level languages, such as C or SQL...

Most important when it comes to variable naming: the name should make very clear what the variable or method is for. Don't save on characters here! :-)
This also reduces the amount of necessary comments in the code!

from yuview.

Ok so we agree on the following:

• Indentation always 2 spaces (no Tabs)
• Unix style LF and UTF-8 encoding for all source files

Things to decide:

• Curly brackets:
  • I actually like the Stroustrup curly bracket style ( no entire line used for just one curly open bracket)
• Variable naming:
  • I am also against type specific namings for variables. Every modern IDE can tell you what type that variable is
• class member variables:
  • I am also against naming class member variables (m_classMember). A modern IDE can also tell you if a variable is a member of a class. It can even tell you more. For example visual studio tells you which class (parent class) the variable belongs to.

from yuview.

• I also prefer the other brackets style:

if()
{
something;
}

• my variable names are usually really long, since I like expressive
  names. I like the m_ prefix because when I type I know I have to start
  every class variable with that.

Unfortunately in QtCreator the style cannot be specified in the .pro file,
but there is a workaround:
http://stackoverflow.com/questions/13993830/how-to-specify-code-style-settings-in-a-qt-creator-pro-shared-file

How about the IDEs you use? If we can create the same style for each and
check it into git, we can make sure nobody accidentally uses different
styles in the future.

On Thu, Nov 19, 2015 at 11:18 AM, Christian [email protected]
wrote:

Ok so we agree on the following:

• Indentation always 2 spaces (no Tabs)
• Unix style LF and UTF-8 encoding for all source files

Things to decide:

• Curly brackets:
  • I actually like the Stroustrup curly bracket style ( no entire
    line used for just one curly open bracket)
• Variable naming:
  • I am also against type specific namings for variables. Every
    modern IDE can tell you what type that variable is
• class member variables:
  • I am also against naming class member variables (m_classMember).
    A modern IDE can also tell you if a variable is a member of a class. It can
    even tell you more. For example visual studio tells you which class (parent
    class) the variable belongs to.

—
Reply to this email directly or view it on GitHub
#20 (comment).

from yuview.

I think we have consensus 😄
I put the style rules into the wiki.

from yuview.