This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

setup.exe contributor guidelines


I think I need to make some of the guidelines I'm using for code review
clear, to aid contributors in making acceptable patches. These are not
set in stone: They are subject to change, via both feedback from you,
and as I think of other things that are relevant. I'll setup a file in
CVS with this at somepoint.

This extends http://www.cygwin.com/ml/cygwin-apps/2002-08/msg00236.html.

Firstly, patch submission:

As per cygwin1.dll:
no changelog in the patch itself.
attach the changelog to the email.
new files are ok in the patch, or as attachments.
ChangeLog as per GNU standards.
One goal per patch. (*)
Multiple patches per email accepted, but my preference is for one patch
per email.

Secondly, Coding standards:
setup has a number of different code formats in it. This is ok as long
as it stays readable. I'll accept patches (if anyone wants to do it :})
to standardise towards what I'm laying out here. But: thats not needed!
Mainly, as code is changed, either leave well enough alone, or refactor
what you are working on accordingly.

The GNU standards are acceptable, but:
They don't explicitly cover C++, and C++ has a number of challenges that
are not met by them. 
If you choose not to follow the GNU standards, then you should follow
these:
* classes or structs to be FirstLetterCapitalised.
* static members and globals to be FirstLetterCapitalised.
* local variables and non-static members to be
capitalisedAfterTheFirstWord.
* hungarian notation is banned.
* Try to keep functions less than 15 lines in length.
* Try to avoid using return values with non-query methods.
* Use classes rather than static functions.
* Place all methods for a single class in a single file. (* Libraries
may need multiple files, this is for setup.exe's source itself)
* Name the source file for classes and their headers after the class.
Capitalise it identically. Where pragmatism requires, try to be as close
as possible (see for instance, String++.h).

I've removed one from the previous list:
* Source to be indented via indent.
Don't do this. indent was too disruptive. astyle does a much better job,
but there are a couple of quirks still to address..


(*) The reason for this is simple: Very few patches will go into CVS at
first submission. Heck, I usually review what I've done 2-3 times after
'completion' before actually committing. Commingled goals will lead to
more effort for the submitter. There are tools to make this separation
of patches easier for submitters. Where relevant, CVS access has been
offer for the use thereof. Accordingly, it is up to the submitter to use
such tools!

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]