![[de]](/mwf/flags/de.png "Germany")
http://wiki.openclonk.org/w/User:Clonkonaut/Style_GuidelinesAs written there: to increase the readability of the scripts.
Reasons for the rules:
Indentation: tabs are more flexible than 2 spaces.
Braces: nothing to discuss here, see poll.
Spaces: separate keywords from normal functions. Increase readability of operators:
5*erk()-2-4/foo()-bar() vs. 5 * erk() - 2 - 4 / foo() - bar()Libraries: just a suggestion.
Still missing: guideline for indenting the actmap proplists.
> Braces: nothing to discuss here, see poll.
The poll was for C++, not C4Script.
Well, I don't see the need to repeat the poll. At first I don't believe that there are 39 (at least) C-coders around here. And then any other rule would lead to inconsistency between our C++ and c4script.
I don't think there are many scripts atm written that way.
The engine source was (is?) as well a mix of styles. The guidelines shall be used from now on to unify the code.
It's actually relatively uniform. Just some of the "rules" (like hungarian notation - but only for some of the variable types) are a bit awkward.
I especially "like" float iSomething :-)And I think lots of people are distracted by the appearance some parts of the engine have when the tabsize is not 2 spaces.
I thought 4 spaces is the standard tabsize
In Clonk source it's 2.That's one of the things that isn't standardized too well, unfortunately. I guess any new code should be written with tabs as indentation only, so the tab size does not matter (and so far, all proposed style guides agree on that).
![[us]](/mwf/flags/us.png "United States")
> // Necessary comment:
> // Create helper object that does foo
> CreateObject(BAR_, 0,0, GetOwner())->foo();
It depends on the situation of course, but I'm not sure I agree this is worth a comment. From the code everybody sees that a (helper) object is created and a function foo() is called. Maybe the comment should rather say why we need a helper object and can't do without.
Ah yeah, that's right. I lacked a good example./e
Changed into something more explanatory (I suppose)
A comment repeating something that can be inferred from the source just sets itself up to be contradicted by the source. One might say that that happening is a good sign that both the code and the comment are wrong, but often enough the comment is just outdated.> // This starts the whole effect, casts particles and stuff
> CreateObject(BAR_, 0,0, GetOwner())->foo();
I'm also a fan of using descriptive names. The improved example wouldn't need a comment if BAR_ were replaced by ParticleCaster and foo by StartEffect.
Aren't we going to replace C4IDs with regular (arbitrary length) identifiers if Guenthers new definition system is used?On the topic of XXX_-IDs, if those happen to stay for a while: The standard used to be XXX1 if the name happened to be very short (ORE1, BOW1, etc.). Imo, this is much better than e.g. BAG_, BAR_, because it always "feels" like an internal ID.
Also, we might consider disallowing the use of local IDs (_XXX) in object packs outside scenarios. Right now, there are some examples of incorrectly used _XXX IDs in the far worlds pack.
> Aren't we going to replace C4IDs with regular (arbitrary length) identifiers if Guenthers new definition system is used?
That's what I thought too...
> Also, we might consider disallowing the use of local IDs (_XXX) in object packs outside scenarios. Right now, there are some examples of incorrectly used _XXX IDs in the far worlds pack.
We could also do proper namespaces - "use Objects.c4d" anyone? :)
Yeah, as soon as somebody has a brilliant idea to distinguish these definition names from global variables and constants. Although there probably will not be a difference from an implementation point of view, the conceptual difference is big enough that it should be reflected in the syntax.
> Objects.c4d/Libraries.c4d
>Prefix with L_
Two things:
When we have identifiers of arbitrary length we could use libFoo or something. And if we have namespaces we could even use lib::Foo
Another thing: It would still be great to be able to include single script files. We wouldn't even need an own definition for each library but could either put "global" library functions in their namespace or - if the library is something to include - include only the scriptfile (Guenther!)
Probably because nobody complained when I suggested that in the C++ guidelines ;)
> Spaces: separate keywords from normal functions.
+
> And then any other rule would lead to inconsistency between our C++ and c4script.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
