I think it would make sense to require a specific coding/commenting format that everyone must follow. It would make reading the code a whole lot easier.
I would write up some guidelines, but I'm afraid that I'd probably get flamed with things like "What kind of insane code format is that?!"
I anyone wants any ideas, feel free to take a look at my PIE article (hopefully soon to be "articles"). http://www.brunslo.com/cessen/pie/pie.php
There should be a CodingStyle directory (or CodingStyleGuide - or ... .html) somewhere in the documentation stuff to be released together with the source code. Maybe we still have to wait a few days for the documentation to come, but there will be a paper on coding style.
I'm happy that it contains instructions on how to get Emacs working with it - since a tab stop is normally at 8 spaces, not at 3 ...
I hope the doc. committee will have some influence on it, since documentation depends on source code and coding style.
After the coding standards are settled, what's needed is an astyle
configuration file included in the source tree that implements the accepted style. All patches should be astyle
d against that file before diffing or checkin.
This way, if a specific developer has a particular coding style that makes it easier for him to work, he can astyle
the files he's working on into his own personal style. That way, he can work "in the zone" without the jarring distraction of a style he's not used to. Then he can astyle
them back to standard when he's done.
It'll also help to clean up any current inconsistencies in the code -- as each file is visited, it's brought up to standard as a matter of course.
If you had provided a link, I wouldn't have had to search it by using google. Hey, that's a hypertext medium, so use it's abilities to provide links and don't waste my time! (I'm actually not very angry about this, just make sure what you write is easy to read and explore (using links).)
What I immediately thought about when I saw your post was GNU Indent: http://www.gnu.org/software/indent/
. There's also some script in the Linux kernel
that uses indent to reformat C code to comply to the coding guidelines of Linux development. I think I even saw a version of Indent for C++ once, but don't know for sure.
|If you had provided a link, I wouldn't have had to search it by using google. Hey, that's a hypertext medium, so use it's abilities to provide links and don't waste my time! (I'm actually not very angry about this, just make sure what you write is easy to read and explore (using links).) |
Oops! My bad!
It would be great to have a script to automate the process. As you noted, GNU Indent doesn't support C++, and generally isn't as fresh or flexible as astyle, which is much more actively maintained.
We'd also need to ensure that a user wouldn't need astyle just to build the application. It should only be needed by active developers.
There's no need to argue about tabs sizes. Everybody knows that indentation should be excactly 8 spaces wide ;-)
From what I have seen of the blender code, tabs are done with the TAB character, not with spaces, which means that you can set whatevr text-editor you like to display it at whatever side you want, and not need to do re-formatting at all.
noid: At the conference, I saw (at the coding style roundtable) that the former NaN coding guidelines included indentation using tabs, and each tab stop being 3 spaces wide. Also, there was a restriction that lines be no wider than 80 spaces (expanding a tab to 3 spaces) wide (I would even restrict that to about 72).
For anybody really interested: you might want to ask Hans Lambermont for a copy of the guidelines. (He was one of the guys presenting them at the conference.) It might not yet be for general publication, but at least you could see what was discussed at the conference.
PS: Of course I know that at least for Unix systems, a tab stop is at every 8 characters.
Dude! That PIE article was great! I think that it's a really god idea, and I'll definetely be using it when I'm working on a big project. I can't wait for the next article!
I've posted a recommendation into the documentation thread based on the contents of this thread
Well, the Blender documentation has now been released, and it includes coding style guidelines! So, I guess this thread is rather moot, now.
Everyone should follow the style guidelines!
btw: pie can be combined with the style guidelines,or not?
|btw: pie can be combined with the style guidelines,or not? |
Yes, they can. PIE is specifically meant not to be code-style-specific. PIE is a programming technique, rather than a code-style (the style used in the article was merely my coding style at the time... it has since changed somewhat). However, the technique does entail some implicit requirements--such as function headers (and the information in them)--simply because of the nature of the programming technique.