Commit 5127372a authored by Per Cederqvist's avatar Per Cederqvist
Browse files

(The Database): Mention that untranslated Swedish text exists.

(local-to-global): Ditto.
(Modifying Stored Types): Mention that dbck needs to be updated.
(Coding conventions): New section.
parent 74312690
\input texinfo
@c $Id: lyskomd.texi,v 1.73 2003/08/19 17:06:43 ceder Exp $
@c $Id: lyskomd.texi,v 1.74 2003/08/20 07:35:18 ceder Exp $
@c %**start of header
@include version.texi
......@@ -1691,11 +1691,15 @@ information on how to restore the database.
* Notes:: Mixed notes.
* Debugging and Testing:: How to test and debug the server.
* local-to-global:: The Local_to_global structure.
* Coding conventions:: Indentation style et c.
@end menu
@node The Database
@section The Database
This section is not translated to English yet. See a comment in the
@file{lyskomd.texi} for the raw Swedish text.
@c FIXME: ramkomd är död! Länge leve LysKOM!
@c FIXME: Jag har tillsammans med Inge kommit på ett sätt att dels få ner
......@@ -2327,6 +2331,10 @@ dependent so that they can deal with the new database format.
@item Don't forget to update the functions in @file{memory.c}
@item Update dbck so that it can convert to the new format.
@item Add as many test cases as are needed for the dbck conversion.
@end enumerate
......@@ -2840,6 +2848,9 @@ The data structure that stores the mapping from local to global text
numbers is currently one of the more advanced structures used by
This section is not translated to English yet. See a comment in the
@file{lyskomd.texi} for the raw Swedish text.
@c FIXME: Translate this
......@@ -2939,6 +2950,72 @@ block:
@end ignore
@node Coding conventions
@section Coding conventions
When I write this chapter, lyskomd is over 13 years old. It shows.
The code looks differently. Here are a few notes on the coding style
that is preferred. When you make a substantial change in a function,
please update it to this style as well.
@itemize @bullet
@item Keep lines to at most 79 characters. (Exception: the DejaGNU
test scripts can be as long as you like. Proper TCL quoting is a
bigger nuisance than overly long lines.)
@item Don't make invisible whitespace changes: don't change tab to
space or vice versa, don't add or remove trailing whitespace. It
makes the output of @samp{cvs diff} harder to read.
@item Document the public API of a function in the @file{.h} file, not
the @file{.c} file.
@item Don't use @samp{Bool} to return a failure indication. Use
@samp{Success} instead. That type has two values: @samp{OK} and
@samp{FAILURE}. They cannot be mistaken, but it isn't obvious if
@samp{TRUE} means that some operation failed or if it succeeded.
@item If a function returns @samp{Bool}, its name should make it clear
what @samp{TRUE} means. Don't call the function
@samp{validate_existing_text}; call it @samp{validate_text_exists}.
(But it might be better to use @samp{Success}.)
@item Follow this indentation example:
some_fun(int x,
int y)
if (x > y)
return x;
if (y == 0
&& x < y)
return x;
return 0;
@end example
@item Don't use redundant braces (as in the first @samp{if} statement
above), unless they help readability (as they do in the second
@samp{if} statement above).
@item If you break a line near a @samp{&&} or @samp{||} (or any other
operator), put the operator at the beginning of the next line.
@item A suitable style for GNU Emacs can be found in
@end itemize
@c ======================================================================
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment