← Back to branch summary

~saurabhanandiit/gtg/exportFixed

« back to all changes in this revision

Viewing changes to HACKING

Merge of my work on liblarch newbase and all the backends ported to liblarch
(which mainly means porting the datastore).
One failing test, will check it.

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
2
2
GTG Hacking Guide
3
3
=================
4
4
 
 
5
Code reference documentation is online at:
 
6
 
 
7
   http://allievi.sssup.it/GTG/
 
8
 
 
9
 
5
10
Testing
6
11
-------
7
12
 
73
78
  ./scripts/pep8.py --repeat FILENAME
74
79
 
75
80
 
 
81
Commenting-out Code
 
82
-------------------
 
83
Try to avoid leaving commented out code in the codebase.  Or at least,
 
84
if some code must be left commented out, also include a comment
 
85
or TODO or FIXME explaining why it was disabled.  If possible include a
 
86
bug lp#.
 
87
 
 
88
Some common reasons why one might create commented code are:
 
89
 
 
90
 a.  I was unsure of my fix
 
91
 b.  I wasn't sure what the original code was supposed to do
 
92
 c.  I needed to disable it to work around some problem
 
93
 d.  I removed or broke other code that this code depends on
 
94
 e.  I started implementing something but haven't finished it yet
 
95
 f.  I need this for debugging problems that might still exist
 
96
 
 
97
Obviously none of these are great situations to be in, but it happens.
 
98
 
 
99
Ideally, commenting out a line of code should be a signal to yourself
 
100
that one of these things has happened, and that you probably should ask
 
101
for help before merging it to trunk, and it should stay in a branch for
 
102
now.
 
103
 
 
104
But that may not always be possible.  So more practically, when
 
105
commenting out code please ALWAYS explain why you commented it out.
 
106
This enables other developers (who may know the code better) to figure
 
107
out and solve the problem.
 
108
 
 
109
So instead of this:
 
110
 
 
111
  #foo.animate(x)
 
112
 
 
113
consider doing it like this:
 
114
 
 
115
  #FIXME:  If x is None, it causes animate() to crash.  But x should
 
116
  #never be None, so this *should* always work.  I can't reproduce the 
 
117
  #crash so can't tell what makes x None.  Leaving it disabled for now
 
118
  #until someone can reproduce it and investigate.  (LP: #12345)
 
119
  #
 
120
  #foo.animate(x)
 
121
 
 
122
Especially, avoid commented out code used for debugging.  Instead of
 
123
this:
 
124
 
 
125
  #print "Testing: ", 1, 2, 3
 
126
 
 
127
consider doing it like this:
 
128
 
 
129
  Log.debug("Testing %d %d %d", 1, 2, 3)
 
130
 
 
131
Historically, there has been code left commented out in the codebase for
 
132
various reasons.  As you run across such code, please help us tidy the
 
133
codebase by either commenting why it's disabled, or remove it.
 
134
 
 
135
 
76
136
API Style
77
137
---------
78
138
Whereever possible, prefer using tid/tagname instead of passing task/tag
106
166
# -*- coding: utf-8 -*-
107
167
# -----------------------------------------------------------------------------
108
168
# Gettings Things Gnome! - a personal organizer for the GNOME desktop
109
 
# Copyright (c) 2008-2009 - Lionel Dricot & Bertrand Rousseau
 
169
# Copyright (c) 2008-2010 - Lionel Dricot & Bertrand Rousseau
110
170
#
111
171
# This program is free software: you can redistribute it and/or modify it under
112
172
# the terms of the GNU General Public License as published by the Free Software