It should probably be updated. The rule of thumb that I always followed
was to code in the same style as Jim, who himself followed the Tcl
Style Guide. That said, it would be good to actually enumerate this
better so that there is no confusion, then work to clean up code that
doesn't follow the style guide. Examples:
Good:
^L
/*
*----------------------------------------------------------------------
*
* NsTclNHttpObjCmd --
*
* Implements the new ns_http to handle HTTP requests.
*
* Results:
* Standard Tcl result.
*
* Side effects:
* May queue an HTTP request.
*
*----------------------------------------------------------------------
*/
int
NsTclNHttpObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj
*CONST objv[])
{
NsInterp *itPtr = arg;
Http *httpPtr;
Tcl_HashEntry *hPtr;
Bad:
^L
/*
*----------------------------------------------------------------------
* Find the specified queue and lock it if found.
*
* Specify "locked" true if the "queuelock" is already locked.
*
* PWM: With the new locking scheme refCount is not longer necessary.
* However, if there is ever a case in the future where an unlocked
* queue can be referenced then we will again need the refCount.
*
* Results:
*
* Side effects:
*
*----------------------------------------------------------------------
*/
static int LookupQueue(Tcl_Interp *interp,
CONST char *queueId,
Queue **queuePtr,
int locked)
{
Tcl_HashEntry *hPtr;
On Feb 24, 2005, at 3:18 PM, Tom Jackson wrote:
On Thursday 24 February 2005 09:37, Nathan Folkman wrote:
Exactly. Thinking of enumerating some higher level guidance:
1. Where ever possible use or wrap core Tcl APIs vs. creating your own
implementation.
2. Tcl APIs should be implemented as Tcl Obj commands.
...etc...
So I have a few questions about the finer details. Reading the Tcl/Tk
Manual,
I have been using these conventions:
1. no tabs, indents are 4 spaces.
2. continuation lines are indented 8 spaces:
3. continuations in if ( ) conditions begin with something that
doesn't look
like a function call: &&, ||, etc.
4. continuations of function prototypes/defs are also indented 8
spaces, not
lined up with the first arg.
5. lines have no trailing whitespace.
There are a lot of differences still in config.c:
1. function prototypes of exported functions are missing.
2. functions are declared with the type on one line and the name on the
following:
char *
Ns_MyChar(...
{
}
Examples:
static int
Poly1305AESObjCmd(ClientData context, Tcl_Interp *interp, int objc,
Tcl_Obj **objv); /* 8 space continuation */
extern void
Ns_Poly1305Authenticate( /* Tcl Manual suggests this style */
char auth[16],
char kr[32],
char nonce[16],
char *message,
unsigned int messageLen); /* each arg on separate line */
static void /* good or
bad */
ConfigSet(char *section, char *key, char *value)
{
Ns_Set *set;
if (section != NULL
&& key != NULL /* indent 8 on continuation,
start && */
&& ( (set = Ns_ConfigGetSection(section)) != NULL) ) {
Ns_SetPut(set, key, value); /* back to 4 indents */
Ns_Log(Debug, "ConfigSet: Added %s = %s to %s", key, value,
section);
} else {
Ns_Log(Debug, "ConfigSet: Unable to add key %s to section %s",
key, section);
}
return;
}
Comment code examples:
The AOLserver style guide says to use ==== where the code actually
uses -----
Below, Ns_ConfigGetSections:
1. follows one blank line after --- line which extends to column 79
2. is indented one space
3. followed by space -- ' --'
3. is followed by a blank line
Description:
1. indented 5 spaces beyond the previous indent, so 6 spaces from the
*
2. continuations are lined up???
3. followed by a blank line.
Overall:
No trailing whitespace
Should text end in a period, or no punctuation?
/*
*----------------------------------------------------------------------
*
* Ns_ConfigGetSections --
*
* Return a malloc'ed, NULL-terminated array of sets, each
* corresponding to a config section
*
* Results:
* An array of sets
*
* Side effects:
* The result is malloc'ed memory
*
*----------------------------------------------------------------------
*/
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
