atsyle formatting options file

[voidptr]

I hope that we can all agree that having a standard formatting style makes things more readable. Even if we don't all work in this style , reformatting before commiting work will stop some misunderstanding and allow faster acclimation of all programmers.

To help with that I've looked over the documents and parts of the source code & have built an atyle formatting options file:

///////////////////////////////////// blender_astyle_options /////////////////////////////////////////////
-t -C -N -l
#indent with tabs (4 default)
#indent classes
#indent namespaces
#break definition brackets but attach block brackets
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

It can be used from the command line as:
$> astyle --options=blender_astyle_options test.cpp

This will reformat the file 'test.cpp' to match the required system. A second file could be setup by you to change the blender source to your own personal formatting style for working on.

Of course this idea was borrowed from a different thread http://www.blender.org/modules.php?op=m ... topic&t=41. And credit should go to them as well: cessen brought the topic up, xitnalta named asytle, & EWLloyd provided the link to astyle http://sourceforge.net/projects/astyle/

Now please take this in the frame of mind it's ment. I only want to see the sources come to a stable standard as fast as possible. If this formatting standard is not acceptable it can be disscussed. But I will continue to lobby for a system that provides this kind of result. This may be a bit presumptuous of me, but like I said I only want blenders source to stabilize as quickly as possible.

If there are no major complaints I would be willing to start a project to reformat the current code base & build it into the make system. I also believe the current documents should be ammended to show that a system like this is in place.

One last comment about this. Some people may react violently to the thought of having to read/write code that is not in their preferred coding style. All I can say is that this reaction should be tempered by the knowledge that there are no 'standards' in coding and every shop I've worked in had different requirements. At each place I've needed to 'relearn' my coding style. Open source projects are no different. The Linux kernel project, GNU, & Apache all have formatting requirements. There is no reason why we shouldn't as well.

Thank you for keeping an open mind,
voidptr

[xitnalta]

Of course this idea was borrowed from a different thread http://www.blender.org/modules.php?op=m ... topic&t=41. And credit should go to them as well: cessen brought the topic up, xitnalta named asytle, & EWLloyd provided the link to astyle http://sourceforge.net/projects/astyle/

Almost - it's the other way round: EWLloyd mentioned it, and I posted the link.

One last comment about this. Some people may react violently to the thought of having to read/write code that is not in their preferred coding style. All I can say is that this reaction should be tempered by the knowledge that there are no 'standards' in coding and every shop I've worked in had different requirements. At each place I've needed to 'relearn' my coding style. Open source projects are no different. The Linux kernel project, GNU, & Apache all have formatting requirements. There is no reason why we shouldn't as well.

Well - does astyle "support" the GNU Coding Standards? (Does it have all the necessary options to do so?) I won't do much on the code base itself, so I don't have a strong opinion on the final shape of Blender's coding standards, but I still prefer the GNU style .

As I see it, the effort you propose here should heavily interact with the documentation team (which I'm formally (non-publically) already proposed to be part of, but let's see). I think that a coding standard should also include a standard on how to document the code by comments so that the comments can automatically be extracted into a low-level technical documentation of the internal structures (and, most importantly, libraries and APIs) of Blender.

[xitnalta]

As I see it, the effort you propose here should heavily interact with the documentation team.

Oops - that was quite a fault! Nobody can really speak of a "team" here, since collaboration and discussion is open to everyone, so everyone can be part of it. It's just that some people show a bit more interest in specific topics and may become moderators.

It might be helpful to have some public blender.org policy available. It would be mainly Ton's ideas, which I can only agree with, but as you see, I have to remember these details as well.