doc/source/developer-manual.sgml

   1 <!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
   2 <!--
   3 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   4  File        :  $Source: /cvsroot/ijbswa/current/doc/source/developer-manual.sgml,v $
   5
   6  Purpose     :  developer manual
   7                 This file belongs into
   8                 ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
   9
  10  $Id: developer-manual.sgml,v 1.4 2001/09/23 10:13:48 swa Exp $
  11
  12  Written by and Copyright (C) 2001 the SourceForge
  13  IJBSWA team.  http://ijbswa.sourceforge.net
  14
  15  Based on the Internet Junkbuster originally written
  16  by and Copyright (C) 1997 Anonymous Coders and
  17  Junkbusters Corporation.  http://www.junkbusters.com
  18 -->
  19
  20 <article id="index">
  21   <artheader>
  22     <title>Junkbuster Developer Manual</title>
  23
  24     <pubdate>$Id: developer-manual.sgml,v 1.4 2001/09/23 10:13:48 swa Exp $</pubdate>
  25
  26     <authorgroup>
  27       <author>
  28         <affiliation>
  29           <orgname>By: Junkbuster Developers</orgname>
  30         </affiliation>
  31       </author>
  32     </authorgroup>
  33
  34     <abstract>
  35       <para>
  36     The developer manual gives the users information on how to help the developer
  37 team. It provides guidance on coding, testing, documentation and other
  38 issues. The Internet Junkbuster is an application
  39 that provides privacy and security to the user of the world wide web.
  40  </para>
  41       <para>
  42 You can find the latest version of the user manual at <ulink
  43 url="http://ijbswa.sourceforge.net/developer-manual/">http://ijbswa.sourceforge.net/developer-manual/</ulink>.
  44 Please see the Contact section in the user-manual if you want to contact the developers.
  45  </para>
  46
  47       <para>
  48   Feel free to send a note to the developers at <email>ijbswa-developers@lists.sourceforge.net</email>.
  49  </para>
  50     </abstract>
  51   </artheader>
  52
  53   <!--   ~~~~~       New section      ~~~~~     -->
  54   <sect1 id="introduction"><title>Introduction</title>
  55     <para>To be filled.
  56 </para>
  57   </sect1>
  58
  59   <!--   ~~~~~       New section      ~~~~~     -->
  60   <sect1 id="quickstart"><title>Quickstart to Junkbuster Development</title>
  61     <para>To be filled.
  62 </para>
  63   </sect1>
  64
  65   <!--   ~~~~~       New section      ~~~~~     -->
  66   <sect1 id="documentation"><title>Documentation Guidelines</title>
  67     <para>
  68         All docs are in SGML format and located in the <computeroutput>doc/source</computeroutput> directory.
  69         </para>
  70         <para>
  71         How do you update the webserver (i.e. the pages on sourceforge)?
  72         <OrderedList Numeration="Arabic">
  73                 <ListItem><Para>
  74         Run <computeroutput>make dok</computeroutput> (which uses the documents in <computeroutput>doc/source</computeroutput> to update all
  75         text files in <computeroutput>doc/text</computeroutput> and to update
  76 all web documents in <computeroutput>doc/webserver</computeroutput>.
  77                 </Para></ListItem>
  78                 <ListItem><Para>
  79         Run <computeroutput>make webserver</computeroutput> which copies all files from
  80 <computeroutput>doc/webserver</computeroutput> to the sourceforge webserver
  81 via scp.
  82                 </Para></ListItem>
  83         </OrderedList>
  84
  85  </sect1>
  86
  87 <!--     <ListItem><Para>be consistent with the redirect script (i.e. the junkbuster program -->
  88 <!--       points via the redirect URL at sf to valid end-points in the document)</Para></ListItem> -->
  89
  90   <!--   ~~~~~       New section      ~~~~~     -->
  91   <sect1 id="coding"><title>Coding Guidelines</title>
  92
  93     <sect2 id="s1"><title>Introduction</title>
  94
  95     <para>This set of standards is designed to make our lives easier.
  96     It is developed with the simple goal of helping us keep the
  97     "new and improved Junkbusters" consistent and reliable. Thus
  98     making maintenance easier and increasing chances of success of
  99     the project.</para>
 100
 101     <para>And that of course comes back to us as individuals. If we
 102     can increase our development and product efficiencies then we
 103     can solve more of the request for changes/improvements and in
 104     general feel good about ourselves. ;-></para>
 105
 106   </sect2>
 107
 108     <sect2 id="s2"><title>Using Comments</title>
 109
 110
 111     <sect3 id="s3"><title>Comment, Comment, Comment</title>
 112
 113     <para><emphasis>Explanation:</></para>
 114
 115     <para>Comment as much as possible without commenting the obvious.
 116     For example do not comment "aVariable is equal to bVariable".
 117     Instead explain why aVariable should be equal to the bVariable.
 118     Just because a person can read code does not mean they will
 119     understand why or what is being done. A reader may spend a lot
 120     more time figuring out what is going on when a simple comment
 121     or explanation would have prevented the extra research. Please
 122     help your brother IJB'ers out!</para>
 123
 124     <para>The comments will also help justify the intent of the code.
 125     If the comment describes something different than what the code
 126     is doing then maybe a programming error is occurring.</para>
 127
 128     <para><emphasis>Example:</></para>
 129 <programlisting>
 130 /* if page size greater than 1k ... */
 131 if ( PageLength() > 1024 )
 132 {
 133     ... "block" the page up ...
 134 }
 135
 136 /* if page size is small, send it in blocks */
 137 if ( PageLength() > 1024 )
 138 {
 139     ... "block" the page up ...
 140 }
 141
 142 This demonstrates 2 cases of "what not to do".  The first is a
 143 "syntax comment".  The second is a comment that does not fit what
 144 is actually being done.
 145 </programlisting>
 146   </sect3>
 147
 148
 149
 150     <sect3 id="s4"><title>Use blocks for comments</title>
 151
 152     <para><emphasis>Explanation:</></para>
 153
 154     <para>Comments can help or they can clutter. They help when they
 155     are differentiated from the code they describe. One line
 156     comments do not offer effective separation between the comment
 157     and the code. Block identifiers do, by surrounding the code
 158     with a clear, definable pattern.</para>
 159
 160     <para><emphasis>Example:</></para>
 161 <programlisting>
 162 /*********************************************************************
 163  * This will stand out clearly in your code!
 164  *********************************************************************/
 165 if ( thisVariable == thatVariable )
 166 {
 167    DoSomethingVeryImportant();
 168 }
 169
 170
 171 /* unfortunately, this may not */
 172 if ( thisVariable == thatVariable )
 173 {
 174    DoSomethingVeryImportant();
 175 }
 176
 177
 178 if ( thisVariable == thatVariable ) /* this may not either */
 179 {
 180    DoSomethingVeryImportant();
 181 }</programlisting>
 182
 183     <para><emphasis>Exception:</></para>
 184
 185     <para>If you are trying to add a small logic comment and do not
 186     wish to "disrubt" the flow of the code, feel free to use a 1
 187     line comment which is NOT on the same line as the code.</para>
 188
 189
 190   </sect3>
 191
 192
 193     <sect3 id="s5"><title>Keep Comments on their own line</title>
 194
 195     <para><emphasis>Explanation:</></para>
 196
 197     <para>It goes back to the question of readability. If the comment
 198     is on the same line as the code it will be harder to read than
 199     the comment that is on its own line.</para>
 200
 201     <para>There are three exceptions to this rule, which should be
 202     violated freely and often: during the definition of variables,
 203     at the end of closing braces, when used to comment
 204     parameters.</para>
 205
 206     <para><emphasis>Example:</></para>
 207 <programlisting>
 208 /*********************************************************************
 209  * This will stand out clearly in your code,
 210  * But the second example won't.
 211  *********************************************************************/
 212 if ( thisVariable == thatVariable )
 213 {
 214    DoSomethingVeryImportant();
 215 }
 216
 217 if ( thisVariable == thatVariable ) /*can you see me?*/
 218 {
 219    DoSomethingVeryImportant(); /*not easily*/
 220 }
 221
 222
 223 /*********************************************************************
 224  * But, the encouraged exceptions:
 225  *********************************************************************/
 226 int urls_read     = 0;     /* # of urls read + rejected */
 227 int urls_rejected = 0;     /* # of urls rejected */
 228
 229 if ( 1 == X )
 230 {
 231    DoSomethingVeryImportant();
 232 }
 233
 234
 235 short DoSomethingVeryImportant(
 236    short firstParam,   /* represents something */
 237    short nextParam     /* represents something else */ )
 238 {
 239    ...code here...
 240
 241 }   /* -END- DoSomethingVeryImportant */
 242 </programlisting>
 243   </sect3>
 244
 245
 246     <sect3 id="s6"><title>Comment each logical step</title>
 247
 248     <para><emphasis>Explanation:</></para>
 249
 250     <para>Logical steps should be commented to help others follow the
 251     intent of the written code and comments will make the code more
 252     readable.</para>
 253
 254     <para>If you have 25 lines of code without a comment, you should
 255     probably go back into it to see where you forgot to put
 256     one.</para>
 257
 258     <para>Most "for", "while", "do", etc... loops _probably_ need a
 259     comment. After all, these are usually major logic
 260     containers.</para>
 261
 262
 263   </sect3>
 264
 265
 266     <sect3 id="s7"><title>Comment All Functions Thoroughly</title>
 267
 268     <para><emphasis>Explanation:</></para>
 269
 270     <para>A reader of the code should be able to look at the comments
 271     just prior to the beginning of a function and discern the
 272     reason for its existence and the consequences of using it. The
 273     reader should not have to read through the code to determine if
 274     a given function is safe for a desired use. The proper
 275     information thoroughly presented at the introduction of a
 276     function not only saves time for subsequent maintenance or
 277     debugging, it more importantly aids in code reuse by allowing a
 278     user to determine the safety and applicability of any function
 279     for the problem at hand. As a result of such benefits, all
 280     functions should contain the information presented in the
 281     addendum section of this document.</para>
 282
 283
 284   </sect3>
 285
 286
 287     <sect3 id="s8"><title>Comment at the end of braces if the
 288     content is more than one screen length</title>
 289
 290     <para><emphasis>Explanation:</></para>
 291
 292     <para>Each closing brace should be followed on the same line by a
 293     comment that describes the origination of the brace if the
 294     original brace is off of the screen, or otherwise far away from
 295     the closing brace. This will simplify the debugging,
 296     maintenance, and readability of the code.</para>
 297
 298     <para>As a suggestion , use the following flags to make the
 299     comment and its brace more readable:</para>
 300
 301     <para>use following a closing brace: } /* -END- if() or while ()
 302     or etc... */</para>
 303
 304     <para><emphasis>Example:</></para>
 305 <programlisting>
 306 if ( 1 == X )
 307 {
 308    DoSomethingVeryImportant();
 309    ...some long list of commands...
 310 } /* -END- if x is 1 */
 311
 312 or:
 313
 314 if ( 1 == X )
 315 {
 316    DoSomethingVeryImportant();
 317    ...some long list of commands...
 318 } /* -END- if ( 1 == X ) */
 319 </programlisting>
 320   </sect3>
 321
 322   </sect2>
 323
 324     <sect2 id="s9"><title>Naming Conventions</title>
 325
 326
 327
 328     <sect3 id="s10"><title>Variable Names</title>
 329
 330     <para><emphasis>Explanation:</></para>
 331
 332     <para>Use all lowercase, and seperate words via an underscore
 333     ('_'). Do not start an identifier with an underscore. (ANSI C
 334     reserves these for use by the compiler and system headers.) Do
 335     not use identifiers which are reserved in ANSI C++. (E.g.
 336     template, class, true, false, ...). This is in case we ever
 337     decide to port JunkBuster to C++.</para>
 338
 339     <para><emphasis>Example:</></para>
 340 <programlisting>
 341 int ms_iis5_hack = 0;</programlisting>
 342
 343     <para><emphasis>Instead of:</></para>
 344
 345     <para>
 346 <programlisting>
 347 int msiis5hack = 0; int msIis5Hack = 0;
 348 </programlisting>
 349 </para>
 350
 351
 352
 353   </sect3>
 354
 355     <sect3 id="s11"><title>Function Names</title>
 356
 357     <para><emphasis>Explanation:</></para>
 358
 359     <para>Use all lowercase, and seperate words via an underscore
 360     ('_'). Do not start an identifier with an underscore. (ANSI C
 361     reserves these for use by the compiler and system headers.) Do
 362     not use identifiers which are reserved in ANSI C++. (E.g.
 363     template, class, true, false, ...). This is in case we ever
 364     decide to port JunkBuster to C++.</para>
 365
 366     <para><emphasis>Example:</></para>
 367 <programlisting>
 368 int load_some_file( struct client_state *csp )</programlisting>
 369
 370     <para><emphasis>Instead of:</></para>
 371
 372     <para>
 373 <programlisting>
 374 int loadsomefile( struct client_state *csp )
 375 int loadSomeFile( struct client_state *csp )
 376 </programlisting>
 377 </para>
 378
 379
 380   </sect3>
 381
 382
 383     <sect3 id="s12"><title>Header file prototypes</title>
 384
 385     <para><emphasis>Explanation:</></para>
 386
 387     <para>Use a descriptive parameter name in the function prototype
 388     in header files. Use the same parameter name in the header file
 389     that you use in the c file.</para>
 390
 391     <para><emphasis>Example:</></para>
 392 <programlisting>
 393 (.h) extern int load_aclfile( struct client_state *csp );
 394 (.c) int load_aclfile( struct client_state *csp )</programlisting>
 395
 396     <para><emphasis>Instead of:</>
 397 <programlisting>
 398 (.h) extern int load_aclfile( struct client_state * ); or
 399 (.h) extern int load_aclfile();
 400 (.c) int load_aclfile( struct client_state *csp )
 401 </programlisting>
 402 </para>
 403
 404
 405   </sect3>
 406
 407
 408     <sect3 id="s13"><title>Enumerations, and #defines</title>
 409
 410     <para><emphasis>Explanation:</></para>
 411
 412     <para>Use all capital letters, with underscores between words. Do
 413     not start an identifier with an underscore. (ANSI C reserves
 414     these for use by the compiler and system headers.)</para>
 415
 416     <para><emphasis>Example:</></para>
 417 <programlisting>
 418 (enumeration) : enum Boolean { FALSE, TRUE };
 419 (#define) : #define DEFAULT_SIZE 100;</programlisting>
 420
 421     <para><emphasis>Note:</> We have a standard naming scheme for #defines
 422     that toggle a feature in the preprocessor: FEATURE_>, where
 423     > is a short (preferably 1 or 2 word) description.</para>
 424
 425     <para><emphasis>Example:</></para>
 426 <programlisting>
 427 #define FEATURE_FORCE 1
 428
 429 #ifdef FEATURE_FORCE
 430 #define FORCE_PREFIX blah
 431 #endif /* def FEATURE_FORCE */
 432 </programlisting>
 433   </sect3>
 434
 435
 436     <sect3 id="s14"><title>Constants</title>
 437
 438     <para><emphasis>Explanation:</></para>
 439
 440     <para>Spell common words out entirely (do not remove vowels).</para>
 441
 442     <para>Use only widely-known domain acronyms and abbreviations.
 443     Capitalize all letters of an acronym.</para>
 444
 445     <para>Use underscore (_) to separate adjacent acronyms and
 446     abbreviations. Never terminate a name with an underscore.</para>
 447
 448     <para><emphasis>Example:</></para>
 449 <programlisting>
 450 #define USE_IMAGE_LIST 1</programlisting>
 451
 452     <para><emphasis>Instead of:</></para>
 453
 454     <para>
 455 <programlisting>
 456 #define USE_IMG_LST 1 or
 457 #define _USE_IMAGE_LIST 1 or
 458 #define USE_IMAGE_LIST_ 1 or
 459 #define use_image_list 1 or
 460 #define UseImageList 1
 461 </programlisting>
 462 </para>
 463
 464
 465   </sect3>
 466
 467   </sect2>
 468
 469
 470     <sect2 id="s15"><title>Using Space</title>
 471
 472
 473
 474     <sect3 id="s16"><title>Put braces on a line by themselves.</title>
 475
 476     <para><emphasis>Explanation:</></para>
 477
 478     <para>The brace needs to be on a line all by itself, not at the
 479     end of the statement. Curly braces should line up with the
 480     construct that they're associated with. This practice makes it
 481     easier to identify the opening and closing braces for a
 482     block.</para>
 483
 484     <para><emphasis>Example:</></para>
 485 <programlisting>
 486 if ( this == that )
 487 {
 488    ...
 489 }</programlisting>
 490
 491     <para><emphasis>Instead of:</></para>
 492
 493     <para>if ( this == that ) { ... }</para>
 494
 495     <para>or</para>
 496
 497     <para>if ( this == that ) { ... }</para>
 498
 499     <para><emphasis>Note:</> In the special case that the if-statement is
 500     inside a loop, and it is trivial, i.e. it tests for a
 501     condidtion that is obvious from the purpose of the block,
 502     one-liners as above may optically preserve the loop structure
 503     and make it easier to read.</para>
 504
 505     <para><emphasis>Status:</> developer-discrection.</para>
 506
 507     <para><emphasis>Example exception:</></para>
 508 <programlisting>
 509 while ( more lines are read )
 510 {
 511    /* Please document what is/is not a comment line here */
 512    if ( it's a comment ) continue;
 513
 514    do_something( line );
 515 }
 516 </programlisting>
 517   </sect3>
 518
 519
 520     <sect3 id="s17"><title>ALL control statements should have a
 521     block</title>
 522
 523     <para><emphasis>Explanation:</></para>
 524
 525     <para>Using braces to make a block will make your code more
 526     readable and less prone to error. All control statements should
 527     have a block defined.</para>
 528
 529     <para><emphasis>Example:</></para>
 530 <programlisting>
 531 if ( this == that )
 532 {
 533    DoSomething();
 534    DoSomethingElse();
 535 }</programlisting>
 536
 537     <para><emphasis>Instead of:</></para>
 538
 539     <para>if ( this == that ) DoSomething(); DoSomethingElse();</para>
 540
 541     <para>or</para>
 542
 543     <para>if ( this == that ) DoSomething();</para>
 544
 545     <para><emphasis>Note:</> The first example in "Instead of" will execute
 546     in a manner other than that which the developer desired (per
 547     indentation). Using code braces would have prevented this
 548     "feature". The "explanation" and "exception" from the point
 549     above also applies.</para>
 550
 551
 552   </sect3>
 553
 554
 555     <sect3 id="s18"><title>Do not belabor/blow-up boolean
 556     expressions</title>
 557
 558     <para><emphasis>Example:</></para>
 559 <programlisting>
 560 structure->flag = ( condition );</programlisting>
 561
 562     <para><emphasis>Instead of:</></para>
 563
 564     <para>if ( condition ) { structure->flag = 1; } else {
 565     structure->flag = 0; }</para>
 566
 567     <para><emphasis>Note:</> The former is readable and consice. The later
 568     is wordy and inefficient. Please assume that any developer new
 569     to the project has at least a "good" knowledge of C/C++. (Hope
 570     I do not offend by that last comment ... 8-)</para>
 571
 572
 573   </sect3>
 574
 575
 576     <sect3 id="s19"><title>Use white space freely because it is
 577     free</title>
 578
 579     <para><emphasis>Explanation:</></para>
 580
 581     <para>Make it readable. The notable exception to using white space
 582     freely is listed in the next guideline.</para>
 583
 584     <para><emphasis>Example:</></para>
 585 <programlisting>
 586 int firstValue   = 0;
 587 int someValue    = 0;
 588 int anotherValue = 0;
 589 int thisVariable = 0;
 590
 591 if ( thisVariable == thatVariable )
 592
 593 firstValue = oldValue + ( ( someValue - anotherValue ) - whatever )
 594 </programlisting>
 595   </sect3>
 596
 597
 598     <sect3 id="s20"><title>Don't use white space around structure
 599     operators</title>
 600
 601     <para><emphasis>Explanation:</></para>
 602
 603     <para>- structure pointer operator ( "->" ) - member operator (
 604     "." ) - functions and parentheses</para>
 605
 606     <para>It is a general coding practice to put pointers, references,
 607     and function parentheses next to names. With spaces, the
 608     connection between the object and variable/function name is not
 609     as clear.</para>
 610
 611     <para><emphasis>Example:</></para>
 612 <programlisting>
 613 aStruct->aMember;
 614 aStruct.aMember;
 615 FunctionName();</programlisting>
 616
 617     <para><emphasis>Instead of:</> aStruct -> aMember; aStruct . aMember;
 618     FunctionName ();</para>
 619
 620
 621   </sect3>
 622
 623
 624     <sect3 id="s21"><title>Make the last brace of a function stand
 625     out</title>
 626
 627     <para><emphasis>Example:</></para>
 628 <programlisting>
 629 int function1( ... )
 630 {
 631    ...code...
 632    return( retCode );
 633
 634 }   /* -END- function1 */
 635
 636
 637 int function2( ... )
 638 {
 639 }   /* -END- function2 */
 640 </programlisting>
 641
 642     <para><emphasis>Instead of:</></para>
 643
 644     <para>int function1( ... ) { ...code... return( retCode ); } int
 645     function2( ... ) { }</para>
 646
 647     <para><emphasis>Note:</> Use 1 blank line before the closing brace and 2
 648     lines afterwards. This makes the end of function standout to
 649     the most casual viewer. Although function comments help
 650     seperate functions, this is still a good coding practice. In
 651     fact, I follow these rules when using blocks in "for", "while",
 652     "do" loops, and long if {} statements too. After all whitespace
 653     is free!</para>
 654
 655     <para><emphasis>Status:</> developer-discrection on the number of blank
 656     lines. Enforced is the end of function comments.</para>
 657
 658
 659   </sect3>
 660
 661
 662     <sect3 id="s22"><title>Use 3 character indentions</title>
 663
 664     <para><emphasis>Explanation:</></para>
 665
 666     <para>If some use 8 character TABs and some use 3 character TABs,
 667     the code can look *very* ragged. So use 3 character indentions
 668     only. If you like to use TABs, pass your code through a filter
 669     such as "expand -t3" before checking in your code.</para>
 670
 671     <para><emphasis>Example:</></para>
 672 <programlisting>
 673 static const char * const url_code_map[256] =
 674 {
 675    NULL, ...
 676 };
 677
 678
 679 int function1( ... )
 680 {
 681    if ( 1 )
 682    {
 683       return( ALWAYS_TRUE );
 684    }
 685    else
 686    {
 687       return( HOW_DID_YOU_GET_HERE );
 688    }
 689
 690    return( NEVER_GETS_HERE );
 691
 692 }
 693 </programlisting>
 694   </sect3>
 695
 696   </sect2>
 697
 698
 699     <sect2 id="s23"><title>Initializing</title>
 700
 701
 702
 703     <sect3 id="s24"><title>Initialize all variables</title>
 704
 705     <para><emphasis>Explanation:</></para>
 706
 707     <para>Do not assume that the variables declared will not be used
 708     until after they have been assigned a value somewhere else in
 709     the code. Remove the chance of accidentally using an unassigned
 710     variable.</para>
 711
 712     <para><emphasis>Example:</></para>
 713 <programlisting>
 714 short anShort = 0;
 715 float aFloat  = 0;
 716 struct *ptr = NULL;</programlisting>
 717
 718     <para><emphasis>Note:</> It is much easier to debug a SIGSEGV if the
 719     message says you are trying to access memory address 00000000
 720     and not 129FA012; or arrayPtr[20] causes a SIGSEV vs.
 721     arrayPtr[0].</para>
 722
 723     <para><emphasis>Status:</> developer-discrection if and only if the
 724     variable is assigned a value "shortly after" declaration.</para>
 725
 726   </sect3>
 727   </sect2>
 728
 729
 730     <sect2 id="s25"><title>Functions</title>
 731
 732
 733
 734     <sect3 id="s26"><title>Name functions that return a boolean as a
 735     question.</title>
 736
 737     <para><emphasis>Explanation:</></para>
 738
 739     <para>Value should be phrased as a question that would logically
 740     be answered as a true or false statement</para>
 741
 742     <para><emphasis>Example:</></para>
 743 <programlisting>
 744 ShouldWeBlockThis();
 745 ContainsAnImage();
 746 IsWebPageBlank();
 747 </programlisting>
 748   </sect3>
 749
 750
 751     <sect3 id="s27"><title>Always specify a return type for a
 752     function.</title>
 753
 754     <para><emphasis>Explanation:</></para>
 755
 756     <para>The default return for a function is an int. To avoid
 757     ambiguity, create a return for a function when the return has a
 758     purpose, and create a void return type if the function does not
 759     need to return anything.</para>
 760
 761
 762   </sect3>
 763
 764
 765     <sect3 id="s28"><title>Minimize function calls when iterating by
 766     using variables</title>
 767
 768     <para><emphasis>Explanation:</></para>
 769
 770     <para>It is easy to write the following code, and a clear argument
 771     can be made that the code is easy to understand:</para>
 772
 773     <para><emphasis>Example:</></para>
 774 <programlisting>
 775 for ( size_t cnt = 0; cnt < blockListLength(); cnt ++ )
 776 {
 777    ....
 778 }</programlisting>
 779
 780     <para><emphasis>Note:</> Unfortunately, this makes a function call for
 781     each and every iteration. This increases the overhead in the
 782     program, because the compiler has to look up the function each
 783     time, call it, and return a value. Depending on what occurs in
 784     the blockListLength() call, it might even be creating and
 785     destroying structures with each iteration, even though in each
 786     case it is comparing "cnt" to the same value, over and over.
 787     Remember too - even a call to blockListLength() is a function
 788     call, with the same overhead.</para>
 789
 790     <para>Instead of using a function call during the iterations,
 791     assign the value to a variable, and evaluate using the
 792     variable.</para>
 793
 794     <para><emphasis>Example:</></para>
 795 <programlisting>
 796 size_t len = blockListLength();
 797
 798 for ( size_t cnt = 0; cnt < len; cnt ++ )
 799 {
 800    ....
 801 }</programlisting>
 802
 803     <para><emphasis>Exceptions:</> if the value of blockListLength() *may*
 804     change or could *potentially* change, then you must code the
 805     function call in the for/while loop.</para>
 806
 807
 808   </sect3>
 809
 810
 811     <sect3 id="s29"><title>Pass and Return by Const Reference</title>
 812
 813     <para><emphasis>Explanation:</></para>
 814
 815     <para>This allows a developer to define a const pointer and call
 816     your function. If your function does not have the const
 817     keyword, we may not be able to use your function. Consider
 818     strcmp, if it were defined as: extern int strcmp( char *s1,
 819     char *s2 );</para>
 820
 821     <para>I could then not use it to compare argv's in main: int main(
 822     int argc, const char *argv[] ) { strcmp( argv[0], "junkbusters"
 823     ); }</para>
 824
 825     <para>Both these pointers are *const*! If the c runtime library
 826     maintainers do it, we should too.</para>
 827
 828
 829   </sect3>
 830
 831
 832     <sect3 id="s30"><title>Pass and Return by Value</title>
 833
 834     <para><emphasis>Explanation:</></para>
 835
 836     <para>Most structures cannot fit onto a normal stack entry (i.e.
 837     they are not 4 bytes or less). Aka, a function declaration
 838     like: int load_aclfile( struct client_state csp )</para>
 839
 840     <para>would not work. So, to be consistent, we should declare all
 841     prototypes with "pass by value": int load_aclfile( struct
 842     client_state *csp )</para>
 843
 844
 845   </sect3>
 846
 847
 848     <sect3 id="s31"><title>Names of include files</title>
 849
 850     <para><emphasis>Explanation:</></para>
 851
 852     <para>Your include statements should contain the file name without
 853     a path. The path should be listed in the Makefile, using -I as
 854     processor directive to search the indicated paths. An exception
 855     to this would be for some proprietary software that utilizes a
 856     partial path to distinguish their header files from system or
 857     other header files.</para>
 858
 859     <para><emphasis>Example:</></para>
 860 <programlisting>
 861 #include &lt;iostream.h&gt;     /* This is not a local include */
 862 #include "config.h"       /* This IS a local include */
 863 </programlisting>
 864
 865     <para><emphasis>Exception:</></para>
 866
 867     <para>
 868 <programlisting>
 869 /* This is not a local include, but requires a path element. */
 870 #include &lt;sys/fileName.h&gt;
 871 </programlisting>
 872 </para>
 873
 874     <para><emphasis>Note:</> Please! do not add "-I." to the Makefile
 875     without a _very_ good reason. This duplicates the #include
 876     "file.h" behaviour.</para>
 877
 878
 879   </sect3>
 880
 881
 882     <sect3 id="s32"><title>Provide multiple inclusion
 883     protection</title>
 884
 885     <para><emphasis>Explanation:</></para>
 886
 887     <para>Prevents compiler and linker errors resulting from
 888     redefinition of items.</para>
 889
 890     <para>Wrap each header file with the following syntax to prevent
 891     multiple inclusions of the file. Of course, replace PROJECT_H
 892     with your file name, with "." Changed to "_", and make it
 893     uppercase.</para>
 894
 895     <para><emphasis>Example:</></para>
 896 <programlisting>
 897 #ifndef PROJECT_H_INCLUDED
 898 #define PROJECT_H_INCLUDED
 899  ...
 900 #endif /* ndef PROJECT_H_INCLUDED */
 901 </programlisting>
 902   </sect3>
 903
 904
 905     <sect3 id="s33"><title>Use `extern "C"` when appropriate</title>
 906
 907     <para><emphasis>Explanation:</></para>
 908
 909     <para>If our headers are included from C++, they must declare our
 910     functions as `extern "C"`. This has no cost in C, but increases
 911     the potential re-usability of our code.</para>
 912
 913     <para><emphasis>Example:</></para>
 914 <programlisting>
 915 #ifdef __cplusplus
 916 extern "C"
 917 {
 918 #endif /* def __cplusplus */
 919
 920 ... function definitions here ...
 921
 922 #ifdef __cplusplus
 923 }
 924 #endif /* def __cplusplus */
 925 </programlisting>
 926   </sect3>
 927
 928
 929     <sect3 id="s34"><title>Where Possible, Use Forward Struct
 930     Declaration Instead of Includes</title>
 931
 932     <para><emphasis>Explanation:</></para>
 933
 934     <para>Useful in headers that include pointers to other struct's.
 935     Modifications to excess header files may cause needless
 936     compiles.</para>
 937
 938     <para><emphasis>Example:</></para>
 939 <programlisting>
 940 /*********************************************************************
 941  * We're avoiding an include statement here!
 942  *********************************************************************/
 943 struct file_list;
 944 extern file_list *xyz;</programlisting>
 945
 946     <para><emphasis>Note:</> If you declare "file_list xyz;" (without the
 947     pointer), then including the proper header file is necessary.
 948     If you only want to prototype a pointer, however, the header
 949     file is unneccessary.</para>
 950
 951     <para><emphasis>Status:</> Use with discrection.</para>
 952
 953
 954   </sect3>
 955   </sect2>
 956
 957     <sect2 id="s35"><title>General Coding Practices</title>
 958
 959
 960
 961     <sect3 id="s36"><title>Turn on warnings</title>
 962
 963     <para><emphasis>Explanation</></para>
 964
 965     <para>Compiler warnings are meant to help you find bugs. You
 966     should turn on as many as possible. With GCC, the switch is
 967     "-Wall". Try and fix as many warnings as possible.</para>
 968
 969
 970   </sect3>
 971
 972
 973     <sect3 id="s37"><title>Provide a default case for all switch
 974     statements</title>
 975
 976     <para><emphasis>Explanation:</></para>
 977
 978     <para>What you think is guaranteed is never really guaranteed. The
 979     value that you don't think you need to check is the one that
 980     someday will be passed. So, to protect yourself from the
 981     unknown, always have a default step in a switch statement.</para>
 982
 983     <para><emphasis>Example:</></para>
 984 <programlisting>
 985 switch( hash_string( cmd ) )
 986 {
 987    case hash_actions_file :
 988       ... code ...
 989       break;
 990
 991    case hash_confdir :
 992       ... code ...
 993       break;
 994
 995    default :
 996       log_error( ... );
 997       ... anomly code goes here ...
 998       continue; / break; / exit( 1 ); / etc ...
 999
1000 } /* end switch( hash_string( cmd ) ) */</programlisting>
1001
1002     <para><emphasis>Note:</> If you already have a default condition, you
1003     are obviously exempt from this point. Of note, most of the
1004     WIN32 code calls `DefWindowProc' after the switch statement.
1005     This API call *should* be included in a default statement.</para>
1006
1007     <para><emphasis>Another Note:</> This is not so much a readability issue
1008     as a robust programming issue. The "anomly code goes here" may
1009     be no more than a print to the STDERR stream (as in
1010     load_config). Or it may really be an ABEND condition.</para>
1011
1012     <para><emphasis>Status:</> Programmer discretion is advised.</para>
1013
1014
1015   </sect3>
1016
1017
1018     <sect3 id="s38"><title>Try to avoid falling through cases in a
1019     switch statement.</title>
1020
1021     <para><emphasis>Explanation:</></para>
1022
1023     <para>In general, you will want to have a 'break' statement within
1024     each 'case' of a switch statement. This allows for the code to
1025     be more readable and understandable, and furthermore can
1026     prevent unwanted surprises if someone else later gets creative
1027     and moves the code around.</para>
1028
1029     <para>The language allows you to plan the fall through from one
1030     case statement to another simply by omitting the break
1031     statement within the case statement. This feature does have
1032     benefits, but should only be used in rare cases. In general,
1033     use a break statement for each case statement.</para>
1034
1035     <para>If you choose to allow fall through, you should comment both
1036     the fact of the fall through and reason why you felt it was
1037     necessary.</para>
1038
1039
1040   </sect3>
1041
1042
1043     <sect3 id="s39"><title>Use 'long' or 'short' Instead of
1044     'int'</title>
1045
1046     <para><emphasis>Explanation:</></para>
1047
1048     <para>On 32-bit platforms, int usually has the range of long. On
1049     16-bit platforms, int has the range of short.</para>
1050
1051     <para><emphasis>Status:</> open-to-debate. In the case of most FSF
1052     projects (including X/GNU-Emacs), there are typedefs to int4,
1053     int8, int16, (or equivalence ... I forget the exact typedefs
1054     now). Should we add these to IJB now that we have a "configure"
1055     script?</para>
1056
1057
1058   </sect3>
1059
1060
1061     <sect3 id="s40"><title>Don't mix size_t and other types</title>
1062
1063     <para><emphasis>Explanation:</></para>
1064
1065     <para>The type of size_t varies across platforms. Do not make
1066     assumptions about whether it is signed or unsigned, or about
1067     how long it is. Do not compare a size_t against another
1068     variable of a different type (or even against a constant)
1069     without casting one of the values. Try to avoid using size_t if
1070     you can.</para>
1071
1072
1073   </sect3>
1074
1075
1076     <sect3 id="s41"><title>Declare each variable and struct on its
1077     own line.</title>
1078
1079     <para><emphasis>Explanation:</></para>
1080
1081     <para>It can be tempting to declare a series of variables all on
1082     one line. Don't.</para>
1083
1084     <para><emphasis>Example:</></para>
1085 <programlisting>
1086 long a = 0;
1087 long b = 0;
1088 long c = 0;</programlisting>
1089
1090     <para><emphasis>Instead of:</></para>
1091
1092     <para>long a, b, c;</para>
1093
1094     <para><emphasis>Explanation:</> - there is more room for comments on the
1095     individual variables - easier to add new variables without
1096     messing up the original ones - when searching on a variable to
1097     find its type, there is less clutter to "visually"
1098     eliminate</para>
1099
1100     <para><emphasis>Exceptions:</> when you want to declare a bunch of loop
1101     variables or other trivial variables; feel free to declare them
1102     on 1 line. You should, although, provide a good comment on
1103     their functions.</para>
1104
1105     <para><emphasis>Status:</> developer-discrection.</para>
1106
1107
1108   </sect3>
1109
1110
1111     <sect3 id="s42"><title>Use malloc/zalloc sparingly</title>
1112
1113     <para><emphasis>Explanation:</></para>
1114
1115     <para>Create a local stuct (on the stack) if the variable will
1116     live and die within the context of one function call.</para>
1117
1118     <para>Only "malloc" a struct (on the heap) if the variable's life
1119     will extend beyond the context of one function call.</para>
1120
1121     <para><emphasis>Example:</></para>
1122 <programlisting>
1123 If a function creates a struct and stores a pointer to it in a
1124 list, then it should definately be allocated via `malloc'.
1125 </programlisting>
1126   </sect3>
1127
1128
1129     <sect3 id="s43"><title>The Programmer Who Uses 'malloc' is
1130     Responsible for Ensuring 'free'</title>
1131
1132     <para><emphasis>Explanation:</></para>
1133
1134     <para>If you have to "malloc" an instance, you are responsible for
1135     insuring that the instance is `free'd, even if the deallocation
1136     event falls within some other programmer's code. You are also
1137     responsible for ensuring that deletion is timely (i.e. not too
1138     soon, not too late). This is known as "low-coupling" and is a
1139     "good thing (tm)". You may need to offer a
1140     free/unload/destuctor type function to accomodate this.</para>
1141
1142     <para><emphasis>Example:</></para>
1143 <programlisting>
1144 int load_re_filterfile( struct client_state *csp ) { ... }
1145 static void unload_re_filterfile( void *f ) { ... }</programlisting>
1146
1147     <para><emphasis>Exceptions:</></para>
1148
1149     <para>The developer cannot be expected to provide `free'ing
1150     functions for C run-time library functions ... such as
1151     `strdup'.</para>
1152
1153     <para><emphasis>Status:</> developer-discrection. The "main" use of this
1154     standard is for allocating and freeing data structures (complex
1155     or nested).</para>
1156
1157
1158   </sect3>
1159
1160
1161     <sect3 id="s44"><title>Add loaders to the `file_list' structure
1162     and in order</title>
1163
1164     <para><emphasis>Explanation:</></para>
1165
1166     <para>I have ordered all of the "blocker" file code to be in alpha
1167     order. It is easier to add/read new blockers when you expect a
1168     certain order.</para>
1169
1170     <para><emphasis>Note:</> It may appear that the alpha order is broken in
1171     places by POPUP tests coming before PCRS tests. But since
1172     POPUPs can also be referred to as KILLPOPUPs, it is clear that
1173     it should come first.</para>
1174
1175
1176   </sect3>
1177
1178
1179     <sect3 id="s45"><title>"Uncertain" new code and/or changes to
1180     exitinst code, use FIXME</title>
1181
1182     <para><emphasis>Explanation:</></para>
1183
1184     <para>If you have enough confidence in new code or confidence in
1185     your changes, but are not *quite* sure of the reprocussions,
1186     add this:</para>
1187
1188     <para>/* FIXME: this code has a logic error on platform XYZ, *
1189     attempthing to fix */ #ifdef PLATFORM ...changed code here...
1190     #endif</para>
1191
1192     <para>or:</para>
1193
1194     <para>/* FIXME: I think the original author really meant this...
1195     */ ...changed code here...</para>
1196
1197     <para>or:</para>
1198
1199     <para>/* FIXME: new code that *may* break something else... */
1200     ...new code here...</para>
1201
1202     <para><emphasis>Note:</> If you make it clear that this may or may not
1203     be a "good thing (tm)", it will be easier to identify and
1204     include in the project (or conversly exclude from the
1205     project).</para>
1206
1207
1208   </sect3>
1209
1210   </sect2>
1211
1212     <sect2 id="s46"><title>Addendum: Template for files and function
1213     comment blocks:</title>
1214
1215     <para><emphasis>Example for file comments:</></para>
1216 <programlisting>
1217 const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.4 2001/09/23 10:13:48 swa Exp $";
1218 /*********************************************************************
1219  *
1220  * File        :  $S<!-- Break CVS Substitution -->ource$
1221  *
1222  * Purpose     :  (Fill me in with a good description!)
1223  *
1224  * Copyright   :  Written by and Copyright (C) 2001 the SourceForge
1225  *                IJBSWA team.  http://ijbswa.sourceforge.net
1226  *
1227  *                Based on the Internet Junkbuster originally written
1228  *                by and Copyright (C) 1997 Anonymous Coders and
1229  *                Junkbusters Corporation.  http://www.junkbusters.com
1230  *
1231  *                This program is free software; you can redistribute it
1232  *                and/or modify it under the terms of the GNU General
1233  *                Public License as published by the Free Software
1234  *                Foundation; either version 2 of the License, or (at
1235  *                your option) any later version.
1236  *
1237  *                This program is distributed in the hope that it will
1238  *                be useful, but WITHOUT ANY WARRANTY; without even the
1239  *                implied warranty of MERCHANTABILITY or FITNESS FOR A
1240  *                PARTICULAR PURPOSE.  See the GNU General Public
1241  *                License for more details.
1242  *
1243  *                The GNU General Public License should be included with
1244  *                this file.  If not, you can view it at
1245  *                http://www.gnu.org/copyleft/gpl.html
1246  *                or write to the Free Software Foundation, Inc., 59
1247  *                Temple Place - Suite 330, Boston, MA  02111-1307, USA.
1248  *
1249  * Revisions   :
1250  *    $L<!-- Break CVS Substitution -->og$
1251  *
1252  *********************************************************************/
1253
1254
1255 #include "config.h"
1256
1257    ...necessary include files for us to do our work...
1258
1259 const char FILENAME_h_rcs[] = FILENAME_H_VERSION;
1260 </programlisting>
1261
1262     <para><emphasis>Note:</> This declares the rcs variables that should be
1263     added to the "show-proxy-args" page. If this is a brand new
1264     creation by you, you are free to change the "Copyright" section
1265     to represent the rights you wish to maintain.</para>
1266
1267     <para><emphasis>Note:</> The formfeed character that is present right
1268     after the comment flower box is handy for (X|GNU)Emacs users to
1269     skip the verbige and get to the heart of the code (via
1270     `forward-page' and `backward-page'). Please include it if you
1271     can.</para>
1272
1273     <para><emphasis>Example for file header comments:</></para>
1274 <programlisting>
1275 #ifndef _FILENAME_H
1276 #define _FILENAME_H
1277 #define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.4 2001/09/23 10:13:48 swa Exp $"
1278 /*********************************************************************
1279  *
1280  * File        :  $S<!-- Break CVS Substitution -->ource$
1281  *
1282  * Purpose     :  (Fill me in with a good description!)
1283  *
1284  * Copyright   :  Written by and Copyright (C) 2001 the SourceForge
1285  *                IJBSWA team.  http://ijbswa.sourceforge.net
1286  *
1287  *                Based on the Internet Junkbuster originally written
1288  *                by and Copyright (C) 1997 Anonymous Coders and
1289  *                Junkbusters Corporation.  http://www.junkbusters.com
1290  *
1291  *                This program is free software; you can redistribute it
1292  *                and/or modify it under the terms of the GNU General
1293  *                Public License as published by the Free Software
1294  *                Foundation; either version 2 of the License, or (at
1295  *                your option) any later version.
1296  *
1297  *                This program is distributed in the hope that it will
1298  *                be useful, but WITHOUT ANY WARRANTY; without even the
1299  *                implied warranty of MERCHANTABILITY or FITNESS FOR A
1300  *                PARTICULAR PURPOSE.  See the GNU General Public
1301  *                License for more details.
1302  *
1303  *                The GNU General Public License should be included with
1304  *                this file.  If not, you can view it at
1305  *                http://www.gnu.org/copyleft/gpl.html
1306  *                or write to the Free Software Foundation, Inc., 59
1307  *                Temple Place - Suite 330, Boston, MA  02111-1307, USA.
1308  *
1309  * Revisions   :
1310  *    $L<!-- Break CVS Substitution -->og$
1311  *
1312  *********************************************************************/
1313
1314
1315 #include "project.h"
1316
1317 #ifdef __cplusplus
1318 extern "C" {
1319 #endif
1320
1321    ... function headers here ...
1322
1323
1324 /* Revision control strings from this header and associated .c file */
1325 extern const char FILENAME_rcs[];
1326 extern const char FILENAME_h_rcs[];
1327
1328
1329 #ifdef __cplusplus
1330 } /* extern "C" */
1331 #endif
1332
1333 #endif /* ndef _FILENAME_H */
1334
1335 /*
1336   Local Variables:
1337   tab-width: 3
1338   end:
1339 */
1340 </programlisting>
1341
1342     <para><emphasis>Example for function comments:</></para>
1343 <programlisting>
1344 /*********************************************************************
1345  *
1346  * Function    :  FUNCTION_NAME
1347  *
1348  * Description :  (Fill me in with a good description!)
1349  *
1350  * Parameters  :
1351  *          1  :  param1 = pointer to an important thing
1352  *          2  :  x      = pointer to something else
1353  *
1354  * Returns     :  0 => Ok, everything else is an error.
1355  *
1356  *********************************************************************/
1357 int FUNCTION_NAME( void *param1, const char *x )
1358 {
1359    ...
1360    return( 0 );
1361
1362 }
1363 </programlisting>
1364
1365     <para><emphasis>Note:</> If we all follow this practice, we should be
1366     able to parse our code to create a "self-documenting" web
1367     page.</para>
1368
1369   </sect2>
1370
1371   </sect1>
1372
1373   <!--   ~~~~~       New section      ~~~~~     -->
1374   <sect1 id="cvs"><title>Version Control Guidelines</title>
1375     <para>To be filled. note on cvs comments. don't comment what you did, comment
1376 why you did it.
1377 </para>
1378   </sect1>
1379
1380   <!--   ~~~~~       New section      ~~~~~     -->
1381   <sect1 id="testing"><title>Testing Guidelines</title>
1382     <para>To be filled.
1383 </para>
1384
1385     <!--   ~~~~~       New section      ~~~~~     -->
1386     <sect2 id="testing-plan"><title>Testplan for releases</title>
1387       <para>
1388 Explain release numbers. major, minor. developer releases. etc.
1389
1390 <OrderedList Numeration="Arabic">
1391           <ListItem><Para>
1392 Remove any existing rpm with rpm -e
1393 </Para></ListItem>
1394           <ListItem><Para>
1395 Remove any file that was left over. This includes (but is not limited to)
1396       <ItemizedList>
1397                 <ListItem><Para>/var/log/junkbuster</Para></ListItem>
1398                 <ListItem><Para>/etc/junkbuster</Para></ListItem>
1399                 <ListItem><Para>/usr/sbin/junkbuster</Para></ListItem>
1400                 <ListItem><Para>/etc/init.d/junkbuster</Para></ListItem>
1401                 <ListItem><Para>/usr/doc/junkbuster*</Para></ListItem>
1402               </ItemizedList>
1403 </Para></ListItem>
1404           <ListItem><Para>
1405 Install the rpm. Any error messages?
1406 </Para></ListItem>
1407           <ListItem><Para>start,stop,status junkbuster with the specific script
1408       (e.g. /etc/rc.d/init/junkbuster stop). Reboot your machine. Does
1409       autostart work?</Para></ListItem>
1410           <ListItem><Para>Start browsing. Does the junkbuster work? Logfile written?</Para></ListItem>
1411           <ListItem><Para>Remove the rpm. Any error messages? All files removed?</Para></ListItem>
1412         </OrderedList>
1413 </para>
1414     </sect2>
1415
1416     <!--   ~~~~~       New section      ~~~~~     -->
1417     <sect2 id="testing-report"><title>Test reports</title>
1418       <para>
1419 Please submit test reports only with the <ulink url="http://sourceforge.net/tracker/?func=add&amp;group_id=11118&amp;atid=395005">test form</ulink>
1420 at sourceforge. Three simple steps:
1421         <ItemizedList>
1422
1423           <ListItem><Para>Select category: the distribution you test on.</Para></ListItem>
1424           <ListItem><Para>Select group: the version of Junkbuster that we are about to release.</Para></ListItem>
1425           <ListItem><Para>Fill the Summary and Detailed Description with something
1426               intelligent (keep it short and precise).</Para>
1427           </ListItem>
1428         </ItemizedList>
1429         Do not mail to the mailinglist (we cannot keep track on issues there).
1430       </para>
1431     </sect2>
1432
1433   </sect1>
1434
1435   <!--   ~~~~~       New section      ~~~~~     -->
1436   <sect1 id="contact"><title>Contact the developers</title>
1437     <para>Please see the user manual for information on how to contact the developers.
1438     </para>
1439   </sect1>
1440
1441   <!--   ~~~~~       New section      ~~~~~     -->
1442   <sect1 id="copyright"><title>Copyright and History</title>
1443     <para>Please see the user manual for information on Copyright and History.
1444     </para>
1445   </sect1>
1446
1447   <!--   ~~~~~       New section      ~~~~~     -->
1448   <sect1 id="seealso"><title>See also</title>
1449     <para>Please see the user manual for information on references.
1450     </para>
1451   </sect1>
1452
1453   <!--
1454
1455   This program is free software; you can redistribute it
1456   and/or modify it under the terms of the GNU General
1457   Public License as published by the Free Software
1458   Foundation; either version 2 of the License, or (at
1459   your option) any later version.
1460
1461   This program is distributed in the hope that it will
1462   be useful, but WITHOUT ANY WARRANTY; without even the
1463   implied warranty of MERCHANTABILITY or FITNESS FOR A
1464   PARTICULAR PURPOSE.  See the GNU General Public
1465   License for more details.
1466
1467   The GNU General Public License should be included with
1468   this file.  If not, you can view it at
1469   http://www.gnu.org/copyleft/gpl.html
1470   or write to the Free Software Foundation, Inc., 59
1471   Temple Place - Suite 330, Boston, MA  02111-1307, USA.
1472
1473   $Log: developer-manual.sgml,v $
1474   Revision 1.4  2001/09/23 10:13:48  swa
1475   upload process established. run make webserver and
1476   the documentation is moved to the webserver. documents
1477   are now linked correctly.
1478
1479   Revision 1.3  2001/09/13 15:27:40  swa
1480   cosmetics
1481
1482   Revision 1.2  2001/09/13 15:20:17  swa
1483   merged standards into developer manual
1484
1485   Revision 1.1  2001/09/12 15:36:41  swa
1486   source files for junkbuster documentation
1487
1488   Revision 1.3  2001/09/10 17:43:59  swa
1489   first proposal of a structure.
1490
1491   Revision 1.2  2001/06/13 14:28:31  swa
1492   docs should have an author.
1493
1494   Revision 1.1  2001/06/13 14:20:37  swa
1495   first import of project's documentation for the webserver.
1496
1497   -->
1498
1499 </article>