Good point. (Speaking as someone who regularly has to be corrected about this
{grin}.)
---
A. Soroka
The University of Virginia Library
On Jun 29, 2015, at 12:57 PM, Andy Seaborne <[email protected]> wrote:
> Good comments - I've made some revisions to the page based on this input.
>
> It reminded me to add a request for pull requests to have commits focused on
> the pull requests/contribution functionality, not details of how the code has
> evolved up to that point (i.e the internal history). Different audiences.
>
> Andy
>
> On 26/06/15 16:12, A. Soroka wrote:
>> Clone URL (Committers only):
>> https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/getting_involved%2Freviewing_contributions.mdtext
>>
>> A. Soroka
>>
>> Index: trunk/content/getting_involved/reviewing_contributions.mdtext
>> ===================================================================
>> --- trunk/content/getting_involved/reviewing_contributions.mdtext
>> (revision 1655891)
>> +++ trunk/content/getting_involved/reviewing_contributions.mdtext
>> (working copy)
>> @@ -29,6 +29,19 @@
>>
>> @author tags will not prevent a contribution being accepted but **should**
>> be removed by the committer who integrates the contribution.
>>
>> +## Code style
>> +
>> +Jena does not have a particular formal code style specification at this
>> time, but here are some simple tips for keeping your contribution in good
>> order:
>> +
>> +- Don't create a method signature that throws checked exceptions that
>> aren't ever actually thrown from the code in that method unless an API
>> supertype specifies that signature. Otherwise, clients of your code will
>> have to include unnecessary handling code.
>> +- Don't leave unused imports in your code. Any IDE can solve that problem
>> with one keystroke. :)
>> +- If a type declares a supertype that isn't a required declaration,
>> consider whether that clarifies or confuses the intent. The former is okay,
>> the latter not so good.
>> +- Minimize the new compiler warnings your patch creates. If you use
>> @SuppressWarnings to hide them, please add a comment explaining the
>> situation or a TODO with a potential future fix that would allow removing
>> the suppression.
>> +- Remove unused local variables or fields or uninteresting unused private
>> methods. If it's debugging detritus, consider replacing it with good logging
>> code for future use, if that seems likely to become useful.
>> +- If there is valuable code in some unused private method, add a
>> @SuppressWarnings("unused") with an explanation of when it might become
>> useful. If there is valuable but unused code inside a used method, consider
>> breaking it out into a private method and adding a
>> @SuppressWarnings("unused") and an explanation.
>> +
>> +
>> +
>> ## Contribution to Apache
>>
>> The Apache License states that any contribution to an Apache project is
>> automatically considered to be contributed to the Apache foundation and thus
>> liable for inclusion in an Apache project **unless** the contributor
>> explicitly states otherwise.
>>
>
