Mercurial > pylearn

comparison doc/v2_planning/coding_style.txt @ 1316:3234913a3642

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Fixed some typos and added a few precisions in commit message guidelines
author Olivier Delalleau <delallea@iro>
date Thu, 07 Oct 2010 16:48:21 -0400
parents 56278ca00b4d
children 7185d194bb7e
comparison
equal deleted inserted replaced
1314:17e9206af22b 1316:3234913a3642
403 short is better, it is not truncated when you do 'hg log') 403 short is better, it is not truncated when you do 'hg log')
404 - The fetch commit message is like "Automated merge with 404 - The fetch commit message is like "Automated merge with
405 https://theanoclone.googlecode.com/hg/". It is too long to ask people to 405 https://theanoclone.googlecode.com/hg/". It is too long to ask people to
406 use the same. I guess "Merge" would be the most logical message to use. 406 use the same. I guess "Merge" would be the most logical message to use.
407 407
408 FB: The proposed guide line 408 FB: The proposed guidelines
409 * A one line summary 409 * A one line summary. Try to keep it short, and provide the information
410 * If needed a blanc line followed by a more detailed summary 410 that seems most useful to other developers: in particular the goal of
411 a change is more useful than its description (which is always
412 available through the changeset patch log). E.g. say "Improved stability
413 of cost computation" rather than "Replaced log(exp(a) + exp(b)) by
414 a * log(1 + exp(b -a)) in cost computation".
415 * If needed a blank line followed by a more detailed summary
411 * Make a commit for each logical modification 416 * Make a commit for each logical modification
412 * This make review easier to do 417 * This makes reviews easier to do
413 * This make debugging easier as we can more easily pinpint error in commit with hg bisect 418 * This makes debugging easier as we can more easily pinpoint errors in commits with hg bisect
414 * NEVER commit reformating change with functionality 419 * NEVER commit reformatting with functionality changes
415 * HG RECORD/DIFF are your friend 420 * HG RECORD/DIFF are your friend
416 * hg record allow you to record select the change to a file to commit 421 * hg record allows you to select which changes to a file should be
417 * hg record force you to review your code! 422 committed
418 * Review your code before commit 423 * hg record / diff force you to review your code, never commit without
424 running one of these two commands first
419 * Stuff from django guide 425 * Stuff from django guide
420 * Write detailed commit messages in the past tense, not present tense. 426 * Write detailed commit messages in the past tense, not present tense.
421 * Good: "Fixed Unicode bug in RSS API." 427 * Good: "Fixed Unicode bug in RSS API."
422 * Bad: "Fixes Unicode bug in RSS API." 428 * Bad: "Fixes Unicode bug in RSS API."
423 * Bad: "Fixing Unicode bug in RSS API." 429 * Bad: "Fixing Unicode bug in RSS API."
424 * Separate bug fixes from feature changes. 430 * Separate bug fixes from feature changes.
425 * ? If fix a ticket, make the message start with "Fixed #abc" 431 * If fix a ticket, make the message start with "Fixed #abc"
426 * Can make a system to change the ticket? 432 * Can make a system to change the ticket?
427 * ? If reference a ticket, make the message start with "Refs #abc" 433 * If reference a ticket, make the message start with "Refs #abc"
428 * Can make a system to put a comment to the ticket? 434 * Can make a system to put a comment to the ticket?
429 435
430 436
431 Tools to help us out 437 Tools to help us out
432 --------------------- 438 ---------------------