Code-style : proposed change to K&R

[jasperblues]

Hi Folks, (AppCoders especially)

Not sure why, but it looks like the code-style is changing. . . anyone check in their personal settings to the project by accident?

I’m happy to change the style, but we should choose something and stick to it.

#98

[alexgarbarev]

Maybe some peices of my code was written in different style (last years I used strong-defined code style on a really big project - it is difficult to immediately change the style).

Some things I don't like in current style:

1. Braces on a new line. I prefer to use K&R style. when braces on new line in functions and method and not defined but recomment to use breaces on same line inside method and functions. I think it is more compact and easy to read.
   For example

if (a > 2)
{
    b = funcB(3);
}
else
{
    b = funcB(4);
}

or

if (a > 2) {
   b = funcA(3);
} else {
   b = funcB(4);
}

2. Also I prefer K&R style for pointer star.
   because it is more related than to ivar

type *p, *m;
//is not same as
type* p, m;
//but same as
typedef type* typeRef;
typeRef p, m;

we used this style because newbies sometimes confused about what star does mean
3) Why .h file below .m file in xcodeproject? I think placing .h about .m is habitually for C/C++/Objective-C developers, correct me if I wrong. I see that it is mixed in typhoon project now.
I usually just click top file to see header and bottom to see implementation without reading extension, but in typhoon project I'm wrong in this, and I have to change the file again

[alexgarbarev]

I am not against a different style, just my subjective thoughts

[jasperblues]

I'm happy to work with whatever you folks finds most comfortable. . . Let's stick with one though. (It's a shame the IDE can't personalize for you, but save in a standard format)

Folks want to change to KnR style? It's more common.

Sent from my iPhone

On Feb 4, 2014, at 1:59 PM, Aleksey Garbarev [email protected] wrote:

Maybe some peices of my code was written in different style (last years I used strong-defined code style on a really big project - it is difficult to immediately change the style).

Some things I don't like in current style:

1. Braces on a new line. I prefer to use K&R style. when braces on new line in functions and method and not defined but recomment to use breaces on same line inside method and functions. I think it is more compact and easy to read.
   For example

if (a > 2)
{
b = funcB(3);
}
else
{
b = funcB(4);
}
or

if (a > 2) {
b = funcA(3);
} else {
b = funcB(4);
}
2) Also I prefer K&R style for pointer star.
because it is more related than to ivar

type p, *m;
//is not same as
type p, m;
//but same as
typedef type* typeRef;
typeRef p, m;
we used this style because newbies sometimes confused about what star does mean
3) Why .h file below .m file in xcodeproject? I think placing .h about .m is habitually for C/C++/Objective-C developers, correct me if I wrong. I see that it is mixed in typhoon project now.
I usually just click top file to see header and bottom to see implementation without reading extension, but in typhoon project I'm wrong in this, and I have to change the file again

—
Reply to this email directly or view it on GitHub.

[drodriguez]

Are there guidelines for the code style? Does the AppCode solution have those? (normally using Xcode here). I have started using ObjClean which warns you when you are breaking the code style. Maybe we can write a summary of the ObjClean questions for the project (a short-ish code snippet should show most of the code style decisions). But first it will be good to know if there is already a code style in place. I try to follow the code around where I’m editing, but sometimes I see contradicting code styles.

[jasperblues]

I actually worked with Lisa helping her to do the objClean Xcode integration (using my Xcode API project) so she owes us a favor ;)

Personally I like the "just format it for me" approach like AppCode or Uncrustify. . there's an Uncrustify plugin for Xcode and a GUI that would certainly allow mirroring the same setting we have in AppCode

Sent from my iPhone

On Feb 4, 2014, at 6:20 PM, Daniel Rodríguez Troitiño [email protected] wrote:

Are there guidelines for the code style? Does the AppCode solution have those? (normally using Xcode here). I have started using ObjClean which warns you when you are breaking the code style. Maybe we can write a summary of the ObjClean questions for the project (a short-ish code snippet should show most of the code style decisions). But first it will be good to know if there is already a code style in place. I try to follow the code around where I’m editing, but sometimes I see contradicting code styles.

—
Reply to this email directly or view it on GitHub.

[jasperblues]

Robert and I did set up a code style and formatting rules. Rules were checked in and the ticket was #98, I think.

Sent from my iPhone

On Feb 4, 2014, at 6:20 PM, Daniel Rodríguez Troitiño [email protected] wrote:

Are there guidelines for the code style? Does the AppCode solution have those? (normally using Xcode here). I have started using ObjClean which warns you when you are breaking the code style. Maybe we can write a summary of the ObjClean questions for the project (a short-ish code snippet should show most of the code style decisions). But first it will be good to know if there is already a code style in place. I try to follow the code around where I’m editing, but sometimes I see contradicting code styles.

—
Reply to this email directly or view it on GitHub.

[drodriguez]

Perfect. I will look at the formatting rules in AppCode and write a short “textual” guide. Then I may commit the ObjClean file, but I think I will let the integration out (to not force everyone to run that build step).

[drodriguez]

So I included the ObjClean plist (as close as I could for the AppCode styles), and a short note in the contributing guide. Anyway, I will try to use AppCode more, so it maintains the style more consistently.

[jasperblues]

@drodriguez Use whichever IDE your prefer. . . we've got all the team members we can handle now (or have we?!) , but I still envision other folks contributing patches and pull requests. . . many of those folks might prefer Xcode like yourself. . So the work you've done is very useful.

[rhgills]

Ideally we shouldn't need a separate code style guide, but at the moment when the styles used in the codebase are somewhat inconsistent it should help. Good work!

I do use K&R style in my own projects and would be in favor of changing to it. However, the most important thing is consistency.

[jasperblues]

I've used both styles in the past and find that:

• if you change it looks really, really wired for a few days. But you soon get used to it.
• changing back has the same effect

Happy to change to whatever the general consensus is.

Sent from my iPhone

On Feb 6, 2014, at 11:32 AM, Robert Gilliam [email protected] wrote:

Ideally we shouldn't need a separate code style guide, but at the moment when the styles used in the codebase are somewhat inconsistent it should help. Good work!

I do use K&R style in my own projects and would be in favor of changing to it. However, the most important thing is consistency.

—
Reply to this email directly or view it on GitHub.

[jasperblues]

Ok folks, let's decide. Cast one of the following votes:

• Don't care
• Current style
• K&R style

[jasperblues]

Don't care

[jasperblues]

Regarding order of .h file and .m file - this is something that AppCode does. . I've reported a bug. Will bump the issue.

[rhgills]

K&R

[eriksundin]

Don't care. As long as we are consistent.

[jasperblues]

I was going to wait for Daniel's vote but it looks like Aleksey (you damn renegade Aleksey! ;) ) has checked in his code-style settings again. . . . let's just run with K&R.

[jasperblues]

Just joking - I don't know how the code-style got checked in. . . but let's run with it anyway. I get the impression that most folks are leaning towards K&R/don't care. . .

[jasperblues]

Here's a nice auto-format tool if you prefer Xcode: https://github.com/travisjeffery/ClangFormat-Xcode

[alexgarbarev]

Hi folks,

I thought we decide to use K&R style.
Wikipedia:

When adhering to K&R, each function has its opening brace at the next line on the same indentation level as its header, the statements within the braces are indented, and the closing brace at the end is on the same indentation level as the header of the function at a line of its own. The blocks inside a function, however, have their opening braces at the same line as their respective control statements; closing braces remain in a line of their own, unless followed by an else or while keyword.

But after reformatting I see different style - each method has its opening brace on the same line..

Jasper, could you check style settings and reformat code again?

[jasperblues]

OK done. Let me know if you see anything else.