ooc-dev team mailing list archive

[Wander Nauta <info@xxxxxxxxxxxxxx>]

Noob here :)

I agree with Amos - # for macro ánd comment seems odd. C and friends use #
for macro's only, and PHP supports # for comments but complains about it. I
wouldn't like using a space to distinguish between a comment (no op) and a
macro (can be disastrous).

Anyhoo, macros are one of the things I don't like about compiled languages.
I think they are the wrong kind of language-in-a-language.

Just my 2c...

Wander

On Wed, May 12, 2010 at 14:34, Amos Wenger <amoswenger@xxxxxxxxx> wrote:

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