[Kst] Style guide, modifications, and review
netterfield at astro.utoronto.ca
Wed Jul 28 03:19:25 CEST 2004
There has been some discussion as to what modifications to other people's
commits are appropriate, and what aren't.
** coding style guide violations. **
-We have a coding style guide in devel-docs. Read it. Follow it. If you
don't like it, convince the list to change it. But lets stay consistent.
-Do not make changes to the code just for the purpose of fixing someone else's
style guide modifications, because it breaks cvs annotations, and forces
re-compiles. BUT: if you are working on some code anyway, feel free to fix
things local to what you are doing.
** review, trivial fixes, optimizations **
-It is appropriate to review other people's commits. I expect it. It makes
for better code.
-If you see a trivial error, or an easy optimization, and you are *sure* you
are right, feel free to fix it. If you are not sure, ping the commiter.
-If someone fixes something you commited, don't be offended!
-If someone pings you, respond! If you don't in, say 24 hours or so (be
reasonable...) you are giving implicit approval of what they want to do.
** class structure for new projects **
-If you are making a big change, or adding new features, discuss what you are
going to do, including new classes and what they do on the list before you
start. While a lack of comments may imply implicit approval, it may also
imply that it just got missed. All relevant parties really ought to comment!
If you aren't getting responses, be persistent. (and don't make people be
persistent with you).
-While UI considerations come first, Class Cleanliness is also mandatory.
-As much as possible, discuss things on the list.
If you disagree with any of these guidelines, discuss it with me. I want this
More information about the Kst