Subject: note of source code formatting

From: Dominik Vogt <[email-masked]>
Date: Wed, 27 Feb 2002 08:55:34 +0100

If anybody has noticed:  I've changed the way I indent my code to
using a basic indentation width of 8 spaces instead of 2.  Nobody
needs to comply with that choice, but when I come across parts of
the code I might reindent it.  The reasons for my change of mind
can be found in the Linux kernel coding style document (usually
/usr/src/linux/Documentation/CodingStyle):

----------------------------- snip ----------------------------
                Chapter 1: Indentation                                          
                                                                                
Tabs are 8 characters, and thus indentations are also 8 characters.             
There are heretic movements that try to make indentations 4 (or even 2!)        
characters deep, and that is akin to trying to define the value of PI to        
be 3.                                                                           
                                                                                
Rationale: The whole idea behind indentation is to clearly define where         
a block of control starts and ends.  Especially when you've been looking        
at your screen for 20 straight hours, you'll find it a lot easier to see        
how the indentation works if you have large indentations.                       
                                                                                
Now, some people will claim that having 8-character indentations makes          
the code move too far to the right, and makes it hard to read on a              
80-character terminal screen.  The answer to that is that if you need           
more than 3 levels of indentation, you're screwed anyway, and should fix        
your program.                                                                   
                                                                                
In short, 8-char indents make things easier to read, and have the added         
benefit of warning you when you're nesting your functions too deep.             
Heed that warning.                                                              
----------------------------- snip ----------------------------

(Note the parts about 'coding 20 straight hours' and 'if you need
more than 3 levels of indentation, you're screwed anyway').

In short, it makes reading the code easier and forces you more to
think about what you code.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 27 Feb 2002 08:59:33 +0100

> /usr/src/linux/Documentation/CodingStyle):
[snip]

Oh, and I want you to take part in this pearl of wisdom from the
same document (about naming conventions):

----------------------------- snip ----------------------------
Encoding the type of a function into the name (so-called Hungarian              
notation) is brain damaged - the compiler knows the types anyway and can        
check those, and it only confuses the programmer.  No wonder MicroSoft          
makes buggy programs.
----------------------------- snip ----------------------------

;-)

Bye

Dominik ^_^  ^_^

---

From: "Michael Kirby" <[email-masked]>
Date: Wed, 27 Feb 2002 07:05:00 -0500

I'm not sure if its relevant, but in our project we found that using an automated tool to force 
all the code into a single format as it went under change control helped immensely when 
comparing versions.  Often different contributors used different editors or conventions.  

I was against the idea of "forcing" a coding convention on individuals, but this turned out to 
be a great compromise.  Each person has their own conventions enforced by whatever tool 
they want, and then on checkin, it converts it into a common form (it turns out to be my 
personal form...because after all...I did set it up :-).  

Now when we do differences across versions, we don't get the preverbial "everything's 
changed".  When we do merges, we actually have a chance of making the merge work.

Mike

On 27 Feb 2002 at 8:55, Dominik Vogt wrote:

> needs to comply with that choice, but when I come across parts of the
> code I might reindent it.  The reasons for my change of mind can be
> found in the Linux kernel coding style document (usually
>          There are heretic movements that try to make indentations 4
> (or even 2!)        characters deep, and that is akin to trying to
> define the value of PI to        be 3.                                
>   
> 
> Rationale: The whole idea behind indentation is to clearly define
> where         a block of control starts and ends.  Especially when
> you've been looking        at your screen for 20 straight hours,
> you'll find it a lot easier to see        how the indentation works if
> you have large indentations.                       
> 
>          the code move too far to the right, and makes it hard to read
> on a              80-character terminal screen.  The answer to that is
> that if you need           more than 3 levels of indentation, you're
> screwed anyway, and should fix        your program.                   
>                
> 
> In short, 8-char indents make things easier to read, and have the
> added         benefit of warning you when you're nesting your
> functions too deep.             Heed that warning.                    
> (Note the parts about 'coding 20 straight hours' and 'if you need more
> than 3 levels of indentation, you're screwed anyway').
> 
> body of a message to [email-masked]. To report problems, send mail
> to [email-masked]
> 

---
[email-masked]
To obtain my PGP public key, mail "SEND PUB KEY" in the 
subject to "[email-masked]"