Version 1.10

.gitignore

@@ -0,0 +1,8 @@
+.svn
+*.log
+*.out
+*.toc
+*.aux
+*.idx
+*.DS_Store
+/takeouts

ASCII.tex

@@ -0,0 +1,87 @@
+% LaTeX source for textbook ``How to think like a computer scientist''
+% Copyright (C) 2009  Thomas Scheffler
+
+
+\chapter{ASCII-Table}
+\label{ASCII-Table}
+\vskip -3em
+
+\begin{tabular}{|c|c|c|c||c|c|c|c|}
+\hline
+Dec & Hex & Oct & Character & Dec & Hex & Oct & Character\\
+\hline
+0 & 0x00 & 000 & NUL & 32 & 0x20 & 040 & SP\\
+1 & 0x01 & 001 & SOH & 33 & 0x21 & 041 & ! \\
+2 & 0x02 & 002 & STX & 34 & 0x22 & 042 & "'\\
+3 & 0x03 & 003 & ETX & 35 & 0x23 & 043 & \# \\
+4 & 0x04 & 004 & EOT & 36 & 0x24 & 044 & \$ \\
+5 & 0x05 & 005 & ENQ & 37 & 0x25 & 045 & \% \\
+6 & 0x06 & 006 & ACK & 38 & 0x26 & 046 & \& \\
+7 & 0x07 & 007 & BEL & 39 & 0x27 & 047 & ' \\
+8 & 0x08 & 010 & BS & 40 & 0x28 & 050 & (  \\
+9 & 0x09 & 011 & TAB & 41 & 0x29 & 051 &  ) \\
+10 & 0x0A & 012 & LF & 42 & 0x2A & 052 & * \\
+11 & 0x0B & 013 & VT & 43 & 0x2B & 053 & + \\
+12 & 0x0C & 014 & FF & 44 & 0x2C & 054 & , \\
+13 & 0x0D & 015 & CR & 45 & 0x2D & 055 & - \\
+14 & 0x0E & 016 & SO & 46 & 0x2E & 056 & . \\
+15 & 0x0F & 017 & SI & 47 & 0x2F & 057 & / \\
+16 & 0x10 & 020 & DLE & 48 & 0x30 & 060 & 0 \\
+17 & 0x11 & 021 & DC1 & 49 & 0x31 & 061 & 1 \\
+18 & 0x12 & 022 & DC2 & 50 & 0x32 & 062 & 2 \\
+19 & 0x13 & 023 & DC3 & 51 & 0x33 & 063 & 3 \\
+20 & 0x14 & 024 & DC4 & 52 & 0x34 & 064 & 4 \\
+21 & 0x15 & 025 & NAK & 53 & 0x35 & 065 & 5 \\
+22 & 0x16 & 026 & SYN & 54 & 0x36 & 066 & 6 \\
+23 & 0x17 & 027 & ETB & 55 & 0x37 & 067 & 7 \\
+24 & 0x18 & 030 & CAN & 56 & 0x38 & 070 & 8 \\
+25 & 0x19 & 031 & EM & 57 & 0x39 & 071 & 9 \\
+26 & 0x1A & 032 & SUB & 58 & 0x3A & 072 & : \\
+27 & 0x1B & 033 & ESC & 59 & 0x3B & 073 & ; \\
+28 & 0x1C & 034 & FS & 60 & 0x3C & 074 & "< \\
+29 & 0x1D & 035 & GS & 61 & 0x3D & 075 & =\\
+30 & 0x1E & 036 & RS & 62 & 0x3E & 076 & "> \\
+31 & 0x1F & 037 & US & 63 & 0x3F & 077 & ? \\
+\hline
+\end{tabular}
+\pagebreak
+
+\begin{longtable}{|c|c|c|c||c|c|c|c|}
+\hline
+Dec & Hex & Oct & Character & Dec & Hex & Oct & Character\\
+\hline
+64 & 0x40 & 100 & @ & 96 & 0x60 & 140 & ` \\
+65 & 0x41 & 101 & A & 97 & 0x61 & 141 & a \\
+66 & 0x42 & 102 & B & 98 & 0x62 & 142 & b \\
+67 & 0x43 & 103 & C & 99 & 0x63 & 143 & c \\
+68 & 0x44 & 104 & D & 100 & 0x64 & 144 & d \\
+69 & 0x45 & 105 & E & 101 & 0x65 & 145 & e \\
+70 & 0x46 & 106 & F & 102 & 0x66 & 146 & f \\
+71 & 0x47 & 107 & G & 103 & 0x67 & 147 & g \\
+72 & 0x48 & 110 & H & 104 & 0x68 & 150 & h \\
+73 & 0x49 & 111 & I & 105 & 0x69 & 151 & i \\
+74 & 0x4A & 112 & J & 106 & 0x6A & 152 & j \\
+75 & 0x4B & 113 & K & 107 & 0x6B & 153 & k \\
+76 & 0x4C & 114 & L & 108 & 0x6C & 154 & l \\
+77 & 0x4D & 115 & M & 109 & 0x6D & 155 & m \\
+78 & 0x4E & 116 & N & 110 & 0x6E & 156 & n \\
+79 & 0x4F & 117 & O & 111 & 0x6F & 157 & o \\
+80 & 0x50 & 120 & P & 112 & 0x70 & 160 & p \\
+81 & 0x51 & 121 & Q & 113 & 0x71 & 161 & q \\
+82 & 0x52 & 122 & R & 114 & 0x72 & 162 & r \\
+83 & 0x53 & 123 & S & 115 & 0x73 & 163 & s \\
+84 & 0x54 & 124 & T & 116 & 0x74 & 164 & t \\
+85 & 0x55 & 125 & U & 117 & 0x75 & 165 & u \\
+86 & 0x56 & 126 & V & 118 & 0x76 & 166 & v \\
+87 & 0x57 & 127 & W & 119 & 0x77 & 167 & w \\
+88 & 0x58 & 130 & X & 120 & 0x78 & 170 & x \\
+89 & 0x59 & 131 & Y & 121 & 0x79 & 171 & y \\
+90 & 0x5A & 132 & Z & 122 & 0x7A & 172 & z \\
+91 & 0x5B & 133 & [ & 123 & 0x7B & 173 & \{ \\
+92 & 0x5C & 134 & $\backslash$ & 124 & 0x7C & 174 & $\mid$\\
+93 & 0x5D & 135 & ] & 125 & 0x7D & 175 & \} \\
+94 & 0x5E & 136 & \^{} & 126 & 0x7E & 176 & "~ \\
+95 & 0x5F & 137 & \_ & 127 & 0x7F & 177 & DEL \\
+\hline
+\end{longtable}
+

Append1.tex

@@ -0,0 +1,212 @@
+% LaTeX source for textbook ``How to think like a computer scientist''
+% Copyright (C) 2009  Thomas Scheffler
+
+
+\chapter{Coding Style}
+\section{A short guide on style}
+\index{style}
+\index{coding style}
+
+
+In the last few sections, I used the phrase ``by convention''
+several times to indicate design decisions that are arbitrary
+in the sense that there are no significant reasons to do things
+one way or another, but dictated by convention.
+
+In these cases, it is to your advantage to be familiar with
+convention and use it, since it will make your programs easier
+for others to understand.  At the same time, it is important to
+distinguish between (at least) three kinds of rules:
+
+\begin{description}
+
+\item[Divine law:]  This is my phrase to indicate a rule that
+is true because of some underlying principle of logic or
+mathematics, and that is true in any programming language
+(or other formal system).  For example, there is no way to
+specify the location and size of a bounding box using fewer
+than four pieces of information.  Another example is that adding
+integers is commutative.  That's part of the definition of
+addition and has nothing to do with C.
+
+\item[Rules of C:]  These are the syntactic and semantic
+rules of C that you cannot violate, because the
+resulting program will not compile or run.  Some are arbitrary;
+for example, the fact that the {\tt =} symbol represents
+assignment and {\em not} equality.  Others reflect
+underlying limitations of the compilation or execution process.
+For example, you have to specify the types of parameters, but
+not arguments.
+
+\item[Style and convention:]  There are a lot of rules that
+are not enforced by the compiler, but that are essential for
+writing programs that are correct, that you can debug and
+modify, and that others can read.  Examples include indentation
+and the placement of squiggly braces, as well as conventions
+for naming variables, functions and types.
+
+\end{description}
+
+In this section I will briefly summarize the coding style used within
+this book. It follows loosely the "Nasa C Style Guide" 
+\footnote{www.scribd.com/doc/6878959/NASA-C-programming-guide}
+and its main
+intent is on readability rather than saving space or typing effort.
+
+%/ref 
+Since C has such a long history of usage, many 
+different coding styles have been developed and used. It is important
+that you can read them and follow one particular scheme in all
+your code. This makes it much more accessible should you find
+yourself in a position where you have to share your work with other 
+people or have to access code written by your younger self - many years ago...
+
+\section{Naming conventions and capitalization rules}
+
+As a general rule, you should always choose meaningful names for 
+your identifiers. Ideally the name of a variable or function already explains
+its behaviour or use.
+
+It may be more typing effort to use a function named  {\tt FindSubString()} 
+rather than  {\tt FndSStr()}. However, the former is almost self describing 
+and might save you a lot in debugging-time.   
+
+\textbf{Don't use single letter variable names!}
+
+Similarly to functions, you should give your variables names that
+speak for themselves and make clear what values will be stored
+by this variable.
+There are few noticeable exceptions to this rule:
+People use {\tt i}, {\tt j} and {\tt k} as counter variables in loops and
+for spacial coordinates people use {\tt x}, {\tt y} and {\tt z}.
+Use these conventions if they suit you. Don't try to invent new
+conventions all by yourself.
+
+
+The following capitalization style shold be used for the different elements in your
+program. The consistent use of one style gives the programmer and the reader
+of the source code a quick way to determine the meaning of different items
+in your program:
+
+
+\begin{description}
+\item[variableNames: ] variable names always start with lower-case, multiple 
+words are separated by capitalizing the first letter. 
+\item[CONSTANTS: ] use all upper case letters. In order to avoid name space
+collisions it might be necessary to use a prefix such as {\tt MY\_CONSTANT}.
+\item[FunctionNames:] start always with upper case and should possibly 
+contain a verb describing the function. Names for functions that test values should 
+start with '{\tt Is}' or '{\tt Are}'.  
+\item[UserDefinedTypes\_t:] always end in '{\tt \_t}'. Type names names must be 
+capitalised in order to avoid conflict with POSIX names.
+\item[pointerNames\_p:] in order to visually separate pointer variables from
+ordinary variables you should consider ending pointers with '{\tt \_p}'.
+\end{description}
+
+%%
+\section{Bracing style}
+
+There exist different bracing or indent styles that serve the goal
+to make your code more readable through the use of a consistent 
+indentation for control block structures.
+The styles differ in the way the braces are indented with the rest
+of the control block.
+This book uses the BSD/Allman Style because its is the most 
+readable of the four. It needs more horizontal space than the K\&R Style
+but it makes it very easy to track opening and closing braces.
+
+When you are writing programs, make sure that you are using one
+style consistently. In larger projects all contributors should agree
+on the style they are using. Modern programming environments like
+Eclipse support you through the automatic enforcement of a single style.
+
+\begin{verbatim}
+/*Whitesmiths Style*/
+   if (condition)            
+       {
+       statement1; 
+       statement2;
+       }
+\end{verbatim}
+
+Is named after Whitesmiths C, an early commercial C compiler that 
+used this style in its examples. Some people refer to it as the 
+One True Brace Style.
+
+\begin{verbatim}
+
+/*GNU Style*/
+   if (condition)
+     {
+       statement1;
+       statement2;
+     }
+\end{verbatim}
+
+Indents are always four spaces per level, with the braces halfway between the outer and inner indent levels.
+
+\begin{verbatim}
+
+/*K&R/Kernel Style*/
+   if (condition) {
+       statement1;
+       statement2;
+   }
+\end{verbatim}
+
+This style is named after the programming examples in the book
+\emph{The C Programming Language} by Brian W. Kernighan and 
+Dennis Ritchie (the C inventors). 
+
+The K\&R style is the style that is hardest to read. 
+The opening brace happens to be at the far right side of the control statement
+and can be hard to find. The braces therefore have different indentation levels.
+Nevertheless, many C programs use this style. So you should be able 
+to read it.
+
+\begin{verbatim}
+
+/*BSD/Allman Style*/
+   if (condition)
+   {
+       statement1;
+       statement2;
+   }
+\end{verbatim}
+
+This style is used for all the examples in this book.
+
+\section{Layout}
+
+Block comments should be used at the top of your file, before all
+function declarations, to explain the purpose of the program and give additional
+information.
+
+You should also use a similar documentation style before every 
+relevant function in your program.
+\begin{verbatim}
+
+/*
+ * File:     test.c
+ * Author:   Peter Programmer
+ * Date:     May, 29th, 2009
+ *
+ * Purpose: to demonstrate good programming
+ *          practise
+ * /
+
+#include <stdlib.h>
+
+/*
+ * main function, does not use arguments
+ */
+
+int main (void)
+{
+    return EXIT_SUCCESS;
+}
+ 
+\end{verbatim}
+
+
+