Sono sempre stato un maniaco dello stile di programmazione a partire dalla

formattazione del codice. Una delle più interessanti guide sullo stile

di programmazione si trova direttamente nei sorgenti del kernel Linux:

<linux-source-directory>/Documentation/CodingStyle

E’ un’ottima documentazione e vorrei condividerla con i miei lettori traducendola in italiano.

Trattandosi di una guida per la scrittura di codice del kernel Linux, sono presenti alcune

riferimenti o paragrafi riguardanti tale tipo di programmazione, ove possibile,

quindi, sarà fornita una versione ritagliata e riadattata per essere di carattere più generale possibile.

CAPITOLO 1: Formattazione

Il carattere speciale “Tab” equivale a 8 caratteri, quindi anche la formattazione

del codice è basata su spazi di 8 caratteri. Ci sono movimenti eretici che provano

ad usare formattazioni basate su spaziature a 4 (o anche 2!) caratteri, questo

equivale a dire che il valore esatto di PI è 3.

Spiegazione razionale: Il concetto che è alla base di una buona formattazione è

di definire in maniera chiara l’inizio e la fine di un blocco di codice. Specialmente

quando hai trascorso 20 ore consecutive a fissare il tuo schermo, troverai molto

 più facile distinguere i vari blocchi se avrai fatto uso di una formattazione più larga.

Ora, qualcuno potrebbe obiettare che, avendo una formattazione basata su spaziature

a 8 caratteri, il codice si sposti troppo velocemente verso destra, rendendolo

di difficile lettura su un schermo di un terminale a 80 caratteri.

 La risposta a questo è che, se tu hai bisogno di più di 3 livelli di profondità,

stai comunque sbagliando e devi sistemare il tuo codice.

In poche parole la formattazione con spaziature a 8 caratteri rende il codice più

 facilmente leggibile e ha il valore aggiunto di avvertirti quando stai annidando troppo in profondità le tue funzioni.

Non inserire più dichiarazioni su una singola linea a meno che non hai qualcosa da nascondere:

	if (condition) do_this;  do_something_everytime;
	

Fatta eccezione per i commenti e la documentazione non vengono mai utilizzati

singoli spazi per la formattazione e l’esempio qui sopra è volutamente errato.

Usa un editor decente e evita di lasciare spazi alla fine delle linee.

Per questa puntata è tutto, nella prossima vedremo come spezzare le righe lunghe di codice e come posizionare le parentesi.

Parte 2

http://henomis.wordpress.com/2007/06/27/programmare-con-stile-1/

SCRIVERE UN KERNEL IN C

Here’s another couple of warnings about using gcc and ld (although these could potentially apply to anycompiler linker). Firstly, gcc likes to put the literal strings used by functions just before the function’s code.

Normally this isn’t a problem, but it’s caught out a few people who try to get their kernels to write “Hello,

world” straight off. Consider this example:

int main(void)

{

char *str = "Hello, world", *ch;

unsigned short *vidmem = (unsigned short*) 0xb8000;

unsigned i;

for (ch = str, i = 0; *ch; ch++, i++)

vidmem[i] = (unsigned char) *ch | 0x0700;

for (;;)

;

}

This code is intended to write the string “Hello, world” into video memory, in white-on-black text, at the

top-left corner of the screen. However, when it is compiled, gcc will put the literal "Hello, world" stringjust before the code for main. If this is linked to the flat binary format and run, execution will start where the

string is, and the machine is likely to crash. There are a couple of alternative ways around this:

Write a short function which just calls main() and halts. This way, the first function in the program

doesn’t contain any literal strings.

Use the gcc option -fwritable-strings. This will cause gcc to put literal strings in the data section

Writing a Kernel in C

3 of 5

of the executable, away from any code.

Of these, the first option is probably preferable. I like to write my entry point function in assembly, where it

can set up the stack and zero the bss before calling main. You’ll find that normal user-mode programs do this,

too: the real entry point is a small routine in the C library which sets up the environment before calling

main(). This is commonly known as the crt0 function.

The other main snag concerns object-file formats. There are two variants of the 32-bit COFF format: one used

by Microsoft Win32 tools, and one by the rest of the world. They are only subtly different, and linkers which

expect one format will happily link the other. The difference comes in the relocations: if you write code in,

say, NASM, and link it using the Microsoft linker along with some modules compiled using Visual C++, the

addresses in the final output will come out wrongly. There’s no real workaround for this, but luckily most

tools that work with the PE format will allow you to emit files in the Win32 format: NASM has its -f win32

option, and Cygwin has the pei-i386 output format.

A major

http://www.osdever.net/tutorials/pdf/ckernel.pdf

DA