Hi Sheldon,
Le 19 juin 06 à 09:35, Sheldon Gill a écrit :
Quentin Mathé wrote:
Link: <http://www.etoile-project.org/etoile/mediawiki/index.php?
title=How_to_contribute_with_code> Feedback welcome. By the way,
if there is no particular disagreement, I think we can make these
Guidelines official, in other words mandatory for any new modules
to be included in the repository.
Some feedback for you...
*) Drop TABs entirely. Makes life easier for all IMHO
Not sure about this one, there are arguments on both sides, though
the last suggestion made by David seems like a wise and balanced choice.
I think the problem with tab is more related to developer tools like
diff, webcvs etc. that don't allow to customize the tab size (on the
fly especially).
In a similar way, webcvs and others expect files encoded in iso-latin
with their usual setup, to me this doesn't mean we shouldn't use utf-8.
*) Changelog lines should have *two* spaces between date & name and
between name & email
2006-06-19 Sheldon Gill <[EMAIL PROTECTED]>
as I understand it, this is the GNU convention BTW
This looks like a really minor point, but I updated the guidelines to
take it in account.
*) Should make asterisks line up like:
/*
* VERY important single line comment
*/
Fixed.
*) Further attention comments should have commentor noted
// FIXME: say who added the comment -SG
Why not, but this may prove to be be a bit boring throughout the day.
Any other opinions ?
*) In the Accessors section the code example has a single line comment
which uses double slashes instead of the recommended single line
/* copy objects from the NSArray to the buffer */
Messages/Methods Arrangement does the same thing so should be
/* Other instance methods */
Fixed.
Might I recommend that this document also be expanded, or linked to
additional information, to cover:
a) documenting code
b) module layout
c) debug coding (use of logs, exceptions etc)
d) use of C int type and use of pointers generally (esp for 64-
bit clean)
It would be nice to have such additional informations, but until a
later point I won't add new sections, I have various other
documentations to improve in a more urgent manner. I will consider
this seriously for a future update though.
The point c) is specially interesting since GNUstep built-in features
for logging are not always convincing (this bizarre --GNU-Debug flag
for turning on particular logging domains is an example) and often
lead to tedious refactoring. For example, how to switch easily and
precisely between the variants of NSLog, depending on what you want
to debug without rewriting a bunch of logging statements.
Thanks a lot for the feedback,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
