<!-- =====================================================================  -->
<!-- This file is an AbiWord document.                                      -->
<!-- AbiWord is a free, Open Source word processor.                         -->
<!-- You may obtain more information about AbiWord at www.abisource.com     -->
<!-- You should not edit this file by hand.                                 -->
<!-- =====================================================================  -->

<!--         Build_ID          = freebird-jeff -->
<!--         Build_Options     = JavaScript:Off Debug:On -->
<!--         Build_Target      = Linux_2.0.33_i386_DBG -->
<!--         Build_CompileTime = 20:01:27 -->
<!--         Build_CompileDate = Mar  9 1999 -->

<awml>
<section COLUMN_GAP="0.25in" NUM_COLUMNS="1">
<p><c PROPS="font-family:courier; font-size:11pt">$Id: AbiSource_ProgrammerGuidelines.abw,v 1.7 1999/03/10 04:54:38 jeff Exp $</c></p>
<p></p>
<p PROPS="text-align:center"><c PROPS="font-size:24pt; font-weight:bold">AbiSource Programmer Guidelines</c></p>
<p PROPS="text-align:center"></p>
<p PROPS="text-align:center"><c PROPS="font-size:11pt">Copyright (C) 1999 AbiSource, Inc. All Rights Reserved.</c></p>
<p PROPS="text-align:center"></p>
<p PROPS="text-align:center"><c PROPS="font-style:italic">Eric W. Sink</c>, <c PROPS="font-family:courier">eric@abisource.com</c></p>
<p PROPS="text-align:center">AbiSource, Inc.</p>
<p PROPS="text-align:center"></p>
<p PROPS="text-align:center"><c PROPS="font-family:courier">$Date: 1999/03/10 04:54:38 $</c></p>
<p PROPS="text-align:center"></p>
<p>1.  Generally, we use Hungarian notation and mixed-case names for variables.  Prefix integer variables with an <c PROPS="font-family:Courier New">i</c> and pointer variables with a <c PROPS="font-family:Courier New">p</c>.  For example, <c PROPS="font-family:Courier New">iNumColumns</c>.</p>
<p></p>
<p>2.  Class member variables should be prefixed with <c PROPS="font-family:Courier New">m_</c>.  For example, <c PROPS="font-family:Courier New">m_pBlockLayout</c>.  Static member variables should be prefixed with s_.</p>
<p></p>
<p>3.  We use C++, but we use it carefully.  We <c PROPS="font-style:normal; font-weight:bold">generally </c>follow the <c PROPS="font-style:italic">C++ Portability Guide</c> document at www.mozilla.org.  Don't use templates, exceptions, multiple inheritance, RTTI, or namespaces.  Avoid multiple inheritance.  The C++ filename suffix is <c PROPS="font-family:Courier New">.cpp</c>. </p>
<p></p>
<p>4.  C is allowed, but if you're writing new code, we'd prefer that you change the suffix to .cpp and compile it as C++.  :-)  The type checking is stronger that way.  If you do use C, do <c PROPS="font-weight:bold">not </c>use C++ style comments (// this is a comment).</p>
<p></p>
<p>5.  We care about compiler warnings.  Turn on the highest warning level of your compiler which is reasonable and fix everything it complains about.  Our goal is to have a warning-free build.  In practice, we usually come very close to that goal.</p>
<p></p>
<p>6.  We care about memory leaks.  Please be very careful about freeing any memory you allocate.  If you don't, someone will probably make you aware of the error of your ways.</p>
<p></p>
<p>7.  Cross-platform (XP) code is very important to us.  Remember that XP code must compile on a wide variety of platforms.  Don't put platform-specific stuff in XP files.  Don't put platform #ifdefs in XP files.  Don't put any code which could be XP in a platform-specific file.  At the time of this writing, AbiWord is approximately 90% XP code, based on line count.  We'd like to keep it that way.</p>
<p></p>
<p>8.  Use  the portability types in abi/src/util.  For example, don't use <c PROPS="font-family:Courier New">unsigned long</c>, use <c PROPS="font-family:Courier New">UT_uint32</c> instead.  There's also <c PROPS="font-family:Courier New">UT_Bool</c>, with its attendant <c PROPS="font-family:Courier New">UT_TRUE</c> and <c PROPS="font-family:Courier New">UT_FALSE</c>.</p>
<p></p>
<p>9.  Keep an eye on Bugzilla.  We believe in the "fix bugs as you go" approach.  Don't let the bug count ever get too high.  When you fix a bug, update Bugzilla to reflect the change in state.</p>
<p></p>
<p>10.  When you check something in, send email about it.  Put the word 'commit' in the subject line of the message.</p>
<p></p>
<p>11.  Design and implement AbiSuite for users, not for programmers.  We're fanatical about developing software which <c PROPS="font-weight:bold">normal </c>people will like to use.  This is more than just the usual cliches about user friendliness.  If you are a programmer, you are definitely not normal.  Quite often, we refer to the example target user as "the church secretary".  When coding a feature, ask yourself if you designed it such that your Mom will like to use it.  If your Mom is a geek too, then refer to someone else's Mom.</p>
<p></p>
<p>12.  Prefix the names of protected or private methods with an underscore.</p>
<p></p>
<p>13.  The curly brace goes on the next line, and it is not indented.  Don't put the curly brace on the same line as the if, and do not indent it.</p>
<p></p>
<p>14.  Indents are 4 spaces or 1 tab.  Tabs are 4 spaces.</p>
<p></p>
<p>15.  Use asserts liberally.  We've provided the <c PROPS="font-family:Courier New">UT_ASSERT </c>macro for just this purpose.  Asserts are good -- they provide you an opportunity to make your assumptions explicit.</p>
<p></p>
<p>16.  Don't use C++ iostreams.  "I consider the use of C++ iostreams to be a bug and will log it." -- Jeff Hostetler, 27 January 1999.  <c PROPS="font-family:Courier New; font-style:normal">:-)</c></p>
<p></p>
<p>17.  Don't break the tree.  This is a Big One.  Some Open Source projects seem to be very forgiving about checking in code which doesn't compile or causes instant crashes.  We're not.  Around here, when someone breaks the tree, we require them to buy donuts.</p>
<p></p>
<p></p>
</section>
</awml>
