[Suggestion] Developing Standards: calling convention

TrinityCore Development TrinityCore Code Discussion
1

The Developing Standards document contains information on bracketing, loop syntax and other useful tid-bits but I noticed it doesn’t contain the preferred method for calling a function when that function has a simple parameter list.

For example, say you have a function that always gets called and it relies on a boolean value passed in to perform some logic: AlwaysCallMe(bool hasGroup)

Now, there are two ways to call this function: Perform IF…THEN logic in the calling function to determine the value to pass for hasGroup or pass the result of an accessor function, if available:

Method 1 (IF…THEN logic):


void CallingFunction()

{

	 // Assumes 'p' is a Player*

	 if (p->isGrouped())

		 AlwaysCallMe(true);

	 else

		 AlwaysCallMe(false);

}

Method 2 (pass result of accessor function):


void CallingFunction()

{

	 // Assumes 'p' is a Player*

	 AlwaysCallMe(p->isGrouped())

}

I think it’s pretty obvious which is easier to read and I think it would be beneficial to add something to the coding standards as to the desired way to call functions.

2

The only thing missing is “use common sense”, less redundancy = good

3

Well, the whole guide could be replaced with that; bracketing: use common sense, function names: use common sense.

The point of a guideline is to spell out in black and white what is expected. When you leave things up to common sense, I think the community has proven that the definition of common sense varies greatly.

4

You got a point for sure but we gotta be able to tell what is “code style” and what is not; the if/else thingie is more related to logic than anything

It’s obvious to me that “method 2” is preferred

I added a link to http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml in the coding standards topic

Use common sense and BE CONSISTENT.
If you are editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around their if clauses, you should, too. If their comments have little boxes of stars around them, make your comments have little boxes of stars around them too.


The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you are saying, rather than on how you are saying it. We present global style rules here so people know the vocabulary. But local style is also important. If code you add to a file looks drastically different from the existing code around it, the discontinuity throws readers out of their rhythm when they go to read it. Try to avoid this.

OK, enough writing about writing code; the code itself is much more interesting. Have fun!

That’s quite “to the point”