ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

I'm not sure. #foo macro vs # comment seems to confusing / easy to make a
mistake.

Ideally one could use # in any context, such as:

Vector3f := #Vector(3, Float)

On Mon, May 10, 2010 at 12:53 PM, Bart van der Werf <bluelive@xxxxxxxxx>wrote:

> # for macros makes sense, what about
>
> #foo macro
> # comment
> #! hashbang
>
>
> On Mon, May 10, 2010 at 11:46 AM, Amos Wenger <amoswenger@xxxxxxxxx>wrote:
>
>> hmm I prefer 4 spaces, and most ooc code is already written that way. If
>> you think it's too much, you're using too much nested structures anyway =)
>>
>> As for the line length I don't really have any strong opinion either way.
>>
>> As for allowing the '#' for single-line comments, I'm not too sure. I was
>> thinking of reserving that character for macros.
>>
>> What do you think?
>>
>> Amos Wenger (nddrylliog)
>>
>>
>> On Mon, May 10, 2010 at 11:41 AM, Bart van der Werf <bluelive@xxxxxxxxx>wrote:
>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Bart van der Werf <bluelive@xxxxxxxxx>
>>> Date: Mon, May 10, 2010 at 11:40 AM
>>> Subject: Re: [Ooc-dev] OOC best practices
>>> To: Friedrich Weber <fred.reichbier@xxxxxxxxxxxxxx>
>>>
>>>
>>> :)
>>>
>>> Indentation: 2 spaces
>>> Line length: no limit (160) 80 is far too short for modern monitors.
>>> Encoding: Utf8 (bom explicitly allowed, suggested, but not required)
>>>
>>> Whitespace:
>>>
>>> space after functionlike keywords(if/while)/blocks to avoid confusion
>>> with calls.
>>> space around operators
>>> nospace inside()
>>> no trailing statements after conditional
>>> allow ommision of {} for single line single statements.
>>> lowerCamelCase for locals/arguments/private fields
>>> UpperCamelCase for globals and types
>>>
>>> Comments:
>>>
>>> besides // and /*(*) i would suggest alowing # as the first char on a
>>> line as a start of a comment.
>>>
>>>
>>>
>>>
>>> On Sun, May 2, 2010 at 2:54 PM, Friedrich Weber <
>>> fred.reichbier@xxxxxxxxxxxxxx> wrote:
>>>
>>>> Huhu!
>>>>
>>>> On 02.05.2010 13:43, Fabien Bourgeois wrote:
>>>> > OOC API isn't already consolidated but, with rock, I think we can say
>>>> > that pretty few things will change around current syntax and grammar.
>>>> >
>>>> > So, can it be interesting to begin to set a *best practices guide* ?
>>>> > The goal isn't to constrain anybody but I think some little rules can
>>>> > help about readability and code reuse.
>>>>
>>>> Yeah, we certainly need this! I'll just throw in my opinion here. :-)
>>>>
>>>> > Can we start to talk about it ? An example can be the Python style
>>>> guide
>>>> > : [http://www.python.org/dev/peps/pep-0008/]. Points that should be
>>>> > discussed :
>>>> >
>>>> > * Indentations
>>>>
>>>> I like Python, I like 4 spaces.
>>>>
>>>> > * Line length
>>>>
>>>> Hm. 79 characters as a guideline?
>>>>
>>>> > * Encodings
>>>>
>>>> UTF-8?
>>>>
>>>> > * Whitespaces
>>>>
>>>> I also like Python's style here, with one exception: Function
>>>> definitions should have a space between the `func` keyword and the
>>>> arguments::
>>>>
>>>>        doSomething: func (...) {
>>>>                /* ... */
>>>>        }
>>>>
>>>> > * Naming conventions
>>>>
>>>> We should use thisStyle for functions and variables, UppercasedCamelCase
>>>> for classes, covers etc. and UPPERCASED for constants (huh, looks so
>>>> aggressive)
>>>> Package names should be lowercased (net/, io/, lang/). I'm not sure
>>>> about modules. What about this: Capitalized if mainly containing a class
>>>> of this name (structs/HashMap), lowercased if the module name is more of
>>>> a description of its contents? (lang/types, ...).
>>>>
>>>> > * Comments
>>>>
>>>> Hm. // for one-line comments, /** */ (oocdoc) for documentation, /* */
>>>> for everything else?
>>>>
>>>> > Apart from style guide, I d'like to talk about documentation. Python
>>>> > (it's my world, sorry) uses docstring
>>>> > [http://www.python.org/dev/peps/pep-0257/]. What's your point of view
>>>> > about standardizing how we should document our ooc projects ?
>>>>
>>>> Well, we theoretically support everything that sphinx supports, with
>>>> some extensions. ooc-docs uses a sphinx extension that adds some
>>>> ooc-specific roles and refs (so you can do :cover:`String` to reference
>>>> String, for example)
>>>>
>>>> > In my mind, if you're allright about using a lightweight markup
>>>> > language, there are two good candidates :
>>>>
>>>> Hm, I smell problems since we're using MD for ORCs and RST for docs. If
>>>> we need a universal choice, I'd also tend to use reStructuredText.
>>>>
>>>> Cheers,
>>>>
>>>> Friedrich
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~ooc-dev
>>>> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~ooc-dev
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~ooc-dev
>>> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ooc-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>