ooc-dev team mailing list archive

[Bart van der Werf <bluelive@xxxxxxxxx>]

# 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
>>
>>
>