ooc-dev team mailing list archive

[Bart van der Werf <bluelive@xxxxxxxxx>]

i suggested # for easier bash/sh repl integration.

On Wed, May 12, 2010 at 2:49 PM, Wander Nauta <info@xxxxxxxxxxxxxx> wrote:

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