[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forgerock-openam-dev
Subject:    [OpenAM-dev] Starting a coding guidelines doc
From:       jonathan.scudder () forgerock ! com (Jonathan Scudder)
Date:       2011-01-10 10:57:06
Message-ID: 209E0C13-0A75-490B-B72A-9812283517B9 () forgerock ! com
[Download RAW message or body]

Hi,

> We'll I have been using
>
>  * Portions Copyrighted [2010] [ForgeRock AS]
> But
>  * Portions Copyrighted 2010 ForgeRock AS
>
> is as valid, I'm ambivalent.

I'd go for the version without the brackets.

>> I have some questions, like:
>> - where to put fields, variable declarations (on the beggining or  
>> ending
>> of a file?)
>
> My preference is at the beginning as that is where I normally put  
> them and the vast majority of the existing code also puts them  
> there. So I would vote for that.

I've always tried to keep code guidelines aligned with the Java coding  
conventions that Sun released back in the day. They are not updated  
for new language features but are still applicable:
http://www.oracle.com/technetwork/java/codeconv-138413.html

This puts static variables then instance variables at the top,  
followed by constructors and then any other methods. So +1 for Steve's  
answer.
A general reference to the coding conventions might cover most of  
these kinds of question.


>> - will we start to use static imports instead of the constant  
>> interface
>> antipattern?
>> (http://download.oracle.com/javase/1.5.0/docs/guide/language/static-import.html
>> )
>
> I see no reason not too, in fact some of the later code does use  
> this; it just has not been a priority.

I haven't looked but have you actually come across any examples of  
this? Static import is a "lesser evil" and I personally prefer to  
qualify static variables I use so that it is clear where the value is  
coming from. I'd hope at any rate that no-one is writing interfaces  
this way now.


>> - max length of class/method/line?
>
> TBD, this varies a massive amount in the existing code.

We can write out the rules on this but I think a checkstyle xml file  
is what we should be aiming for so that developers can drop it into  
their IDE and get warnings whenever they overstep the mark. We can  
also integrate this into a continuous integration solution so that,  
say, the number of checkstyle errors doesn't need to be 0, but must be  
less that before. A format xml would also be useful for NetBeans.

Cheers,
-Jonathan

--


  	Jonathan Scudder : ForgeRock AS
e: jonathan.scudder at forgerock.com
t: +47 40246904
w: www.forgerock.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.forgerock.org/pipermail/openam-dev/attachments/20110110/4821ee08/attachment.html 

[prev in list] [next in list] [prev in thread] [next in thread]