Poll
Choose all styles you can live with, please! (Closed)
| 1 | 21 | 25% | |
| 2 | 17 | 20% | |
| 3 | 39 | 46% | |
| 4 | 8 | 9% |
![[de]](/mwf/flags/de.png "Germany")
1.int foo (int bar) {
if (1) {
return 2;
} else {
return 3;
}
}2.
int foo (int bar)
{
if (1) {
return 2;
} else {
return 3;
}
}3.
int foo (int bar)
{
if (1)
{
return 2;
}
else
{
return 3;
}
}4.
int foo (int bar)
{
if (1)
{
return 2;
}
else
{
return 3;
}
}See also http://wiki.openclonk.org/w/User:Isilkor/Style_Guidelines
![[ca]](/mwf/flags/ca.png "Canada")
Whoops. I suppose I shouldn't have voted in that case.
> See also http://wiki.openclonk.org/w/User:Isilkor/Style_Guidelines
Also please let us know of your concerns or thoughts about the above draft (which only concerns C++ code, not C4Script).
Good job Isilkor. I like guidelines and conventions. :DBut one question:
You wrote that template casts should be used instead of C-style or function style (C++-Style?) casts.
In my programs I use always 'function' style casts... have the template casts a big advantage?
You get a compiler error if two types are inconvertible and you're using a C++ style cast. If you use C style casts, your program will compile and then probably fail spectacularly at runtime.
![[es]](/mwf/flags/es.png "Spain")
I just broke the habit of scripting in 1 to code in 3 but to all except 4 I can adjust.
Hm. The popularity of #3 at least somewhat explains why it keeps on creeping into the engine source code despite #4 being used in the vast majority of source files.And I'm disappointed that the percentages indicate show many of the votes are for an option, not how many of the voters voted for that option. That way we could know whether one option is acceptable by the majority.
The mwf-mulitiple choice polls have never been meaningful as far as I remember.
I would like something like:
int foo (int bar)
{
if (1) {
return 2;
}
else {
return 3;
}
}
That is a rather odd scheme. Is there some code out there that uses it, or is it your invention?
Ever read through the InExantros-Code? (
Pearsyntax ftw.
Since #3 is the most popular one, I will switch to it now for new code. Could we get an agreement on this? Do you think it would make sense to do an automatic conversion of all engine code? (thinking of future branch merging/rebase now)
> Could we get an agreement on this?
I'm already using #3 for new code.
> Do you think it would make sense to do an automatic conversion of all engine code?
Last thing I heard there isn't a tool available that gets C++ code right, but I might be mistaken.
[Edit] astyle might do a reasonable job, but I haven't tried.
> Last thing I heard there isn't a tool available that gets C++ code right, but I might be mistaken.
Well, I said I didn't know one, and knew that indent doesn't work, not that there isn't one. Though it's quite possible that nobody has yet written a tool which works for all corner cases C++ offers. And as I don't like style #3, I'm not inclined to waste work on this :-)
I don't think we should use full automatic formatting. Better do some conversion that exactly catches consistent usage of one of the other styles.
After all, there are cases where the indention rules are broken with full intention. I remember doing hundreds of
and still think everything else would be a waste of space.
Maybe I'll code something up. Seems like a fun thing to do with Haskell. Though I'm not really convinced that it's worth it.
After all, there are cases where the indention rules are broken with full intention. I remember doing hundreds of
if(!SomeOperation(...))
{ Log("Error!"); return FALSE; }and still think everything else would be a waste of space.
Maybe I'll code something up. Seems like a fun thing to do with Haskell. Though I'm not really convinced that it's worth it.
If nobody volunteers to change the engine in this regard, I'll declare style #4 as the winner, simply because it's used by the majority of the engine source code and I can live with it. I'm also volunteering to change the few places using #3 to #4.
I will volunteer to try to use indent or something to get everything to conform to option #1, if that helps.Edit: How does http://github.com/ben0x539/openclonk/commit/braces look to everybody? The engine still runs so I assume everything went well!
Or to the winner, option 3? :<
No way, Indentation must be done with tabs. As for testing, do a diff of the resulting executable with the previous version. There should only be minor differences if any.My personal opinion on brace style, by the way, is that (a) consistency is good, (b) whitespace-only changes rarely are worth the hassle, thus I'd prefer to only do the minimum amount of changes necessary to achieve constistency, which in the case of the Clonk engine means changing the few places using #3 to #4, (c) lines with only one brace on them are a waste of horizontal space, thus I prefer style #1. This means that I cannot get all my wishes, but I certainly had hoped that I would get at least one...
> As for testing, do a diff of the resulting executable with the previous version. There should only be minor differences if any.
Lots of vaguely differing numbers, not sure what exactly to take away from this. http://ilfirin.org/clonk-disassembled.diff.txt
Also this:
$ for file in `find CMakeFiles -name *.o` ; do diff $file ../openclonk-old/$file ; done
Files CMakeFiles/clonk.dir/src/editor/C4ObjectListDlg.cpp.o and ../openclonk-old/CMakeFiles/clonk.dir/src/editor/C4ObjectListDlg.cpp.o differ
Files CMakeFiles/clonk.dir/src/editor/C4Console.cpp.o and ../openclonk-old/CMakeFiles/clonk.dir/src/editor/C4Console.cpp.o differ
I had hoped that either one of my favorite options would win, or that somebody else would do the work to convert the engine to the winning style. That's not an unreasonable hope, and if nobody cares enough to do the work, they can't complain if their favorite choice isn't used.
http://github.com/ben0x539/openclonk/commit/allman should be reasonably close to the winning style, I suppose.Edit: In as 786734358061
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
