deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: basic decisions - coding conventions
Date Fri, 16 Dec 2011 18:14:07 GMT
On Thu, Dec 15, 2011 at 5:27 PM, Jason Porter <lightguard.jp@gmail.com> wrote:
> Just to clarify
>
> +1 (binding) to what we currently have listed in the JIRA.

I'll step in and do some mentoring here.  :)  The concept of a binding
vote typically* only comes into play on a thread that is explicitly
declared as a [VOTE].  I say "typically" because a project's
decision-making process *can* be customized; thus it is theoretically
possible that we could set a rule in DeltaSpike that all discussions
are implicitly votes and invoke voting semantics.  I personally think
this would be heavy-handed and not a good idea.

I'll start a separate thread to, briefly, continue the subject of
decision-making.

Matt

>
> On Thu, Dec 15, 2011 at 16:06, Jason Porter <lightguard.jp@gmail.com> wrote:
>
>> imo whitespace is a must, it helps with readability. I'm fine with
>> everything else
>>
>>
>> On Thu, Dec 15, 2011 at 14:02, Matthias Wessendorf <matzew@apache.org>wrote:
>>
>>> > 5) a space between keyword and round bracket (e.g. if (...) instead of
>>> if(...))
>>> > 6) a space before and after an operand (e.g. a = 1 + 2 or a != b
>>> > instead of a=1+2 or a!=b)
>>> >
>>> > 5 and 6 are not soo important, but IMO very nice to have.
>>>
>>>
>>> I hate: if(){
>>>
>>> :-)
>>>
>>> >
>>> > Regards,
>>> > Jakob
>>> >
>>> > 2011/12/12 Shane Bryzak <sbryzak@gmail.com>:
>>> >> On Mon, Dec 12, 2011 at 9:37 PM, Mark Struberg <struberg@yahoo.de>
>>> wrote:
>>> >>
>>> >>> Hi!
>>> >>>
>>> >>> I'm a fan of a pretty tight coding convention observation even at
>>> build
>>> >>> time.
>>> >>>
>>> >>> What we usually have (in owb and myfaces) is an own 'buildtools'
>>> project
>>> >>> which contains the checkstyle rules as own artifact.
>>> >>> This will then be used in the deltaspike-parent pom as dependency
of
>>> the
>>> >>> maven-checkstyle-plugin. I'll set this up, no worries, easy stuff.
>>> >>>
>>> >>> The more important thing is to decide _which_ coding conventions
we
>>> like
>>> >>> to follow at all?
>>> >>>
>>> >>> I have the following suggestions:
>>> >>>
>>> >>> 1.) no tabs, only spaces!
>>> >>>
>>> >>
>>> >> +1, tabs suck
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> 2.) bracelets on new line? Actually I don't care about
>>> >>> > if()
>>> >>> > {
>>> >>> >   dings();
>>> >>> > }
>>> >>> or
>>> >>>
>>> >>> > if() {
>>> >>> >   dings();
>>> >>> > }
>>> >>> but we should only use one stile throughout the whole code.
>>> >>>
>>> >>>
>>> >>
>>> >> I don't mind either way here, comfortable with either as long as we
>>> pick
>>> >> one and are consistent with it.
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> 3.) force bracelets
>>> >>>
>>> >>>  no
>>> >>>
>>> >>> > if()
>>> >>>
>>> >>> >   dosomething;
>>> >>>
>>> >>> without bracelets. Instead force:
>>> >>> > if()
>>> >>> > {
>>> >>>
>>> >>> >   dosomething;
>>> >>> > }
>>> >>>
>>> >>>
>>> >> +1
>>> >>
>>> >>
>>> >>>
>>> >>> I'm sure there is a bit more, thus please add the rules which are
>>> >>> important for you.
>>> >>> (PS: once we found a final solution we should move this into our
wiki
>>> +
>>> >>> provide Eclipse and Idea checkstyle rules.
>>> >>>
>>> >>
>>> >>
>>> >> One thing to decide is indent size.  Currently in Seam we use 4
>>> spaces, as
>>> >> we've recently adopted the JBoss coding standards.  Personally, I think
>>> >> this is a little too much, previously we had 3 spaces (Gavin's
>>> preference)
>>> >> which I thought was better.
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>> LieGrue,
>>> >>> strub
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>> > --
>>> > Jakob Korherr
>>> >
>>> > blog: http://www.jakobk.com
>>> > twitter: http://twitter.com/jakobkorherr
>>> > work: http://www.irian.at
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Jason Porter
>> http://lightguard-jp.blogspot.com
>> http://twitter.com/lightguardjp
>>
>> Software Engineer
>> Open Source Advocate
>> Author of Seam Catch - Next Generation Java Exception Handling
>>
>> PGP key id: 926CCFF5
>> PGP key available at: keyserver.net, pgp.mit.edu
>>
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu

Mime
View raw message