[Yact-dev] Re: Source code

[Marius S. <ma...@fi...>]

Firstly, look the subject line:

Re: [Qbf-dev] Re: [Yact-dev] Source code

Could you fix the prefix for the mailing lists as I suggested in some other 
mail?

[GNU vs ANSI indention]

No, because with the current (GNU) indentation the visual difference
between a simple statement and a compound statement is minimal.  ;)
Compare it with how you would write it using the comma operator:

if ()
	a,
	b,
	c;

Sounds good... in theory (again).  How often do you use the comma operator 
like that?  I never do.

Since the braces are part of the statement list, they should also get
the same indentation.

 From a language design point of view, I guess braces is to be considered 
as statements, just as other languages uses 'begin' and 'end'.  Personally, 
I don't find the code easier to read by considering them as such.  In fact, 
I use similar indention style in SML ('let', 'in', and 'end').

It is a matter of personal taste (religion?), I guess, so discussing it 
will bear just as much fruit as discussing which of red and blue that is 
the prettiest color.

 > Btw:  What tab size do you use?

4.  I can add a little /* vim: ts=4 */ at the end of the files, if you
want.  Emacs have something like that too, right?

I've set the tab size to 4 too, yes.  I just wondered, because some of the 
code looked a bit weird :-)

Be glad that I don't use tabsize *3*, I've seen that one too... :)

And I thought about switching to proportional fonts and using an indention 
of 3.7 :-)

If you need to look at the documentation of a method I've written to
understand what it does, the code is bad and should be rewritten...

Well... It's faster to read an (abstract) comment than to look at the 
(detailed) code.

 > Also, I feel that it is much easier to "forget" the documentation when
 > it's in the header file and thus become obsolete.

Good point.  On the other hand, a header file is usually (but not
always) shorter than the cpp file, which makes it easier and faster to
browse and print.

What I find convenient about header files is that I can look at it and get 
an overview of all a class provides.  This is how I use them, and thus I 
write them compactly, with no comments, and a function or variable on each 
line.  That way, I get an overview of pretty much all classes on one single 
screen (I have a 19").

Also, I don't have a printer...

 > As you know, better programming languages than C++ doesn't separate
 > the interface from the code, and in such languages, you'll have
 > everything in one place, i.e., the code and documentation will be
 > together.

Haven't you gotten over Java, yet? ;)

:-)

I never liked Java.  I was thinking of Eiffel.

 > I try to get "rid of" the header files altogether (as far as possible)
 > by placing the documentation in the code, and some day, also
 > automatically update the header files as needed when I change
 > something in the CPP file (such as adding a new function).

Unfortunately C++ has several things in the header file that can't be
put in the cpp file, which makes it kind of hard.

I don't mean to remove the header files.  I just don't want to touch them 
too much.  Touch one and the compilator often goes ahead and recompiles 
pretty much everything.

 > >It also makes it easier to write interface classes, and they have no
 > >.cpp file at all. ;)
 >
 > Well, I think that should be the exception rather than the rule.

Interfaces are good, and there will be more of them later.  MI is ok, as
long as one doesn't have attributes in more than one class.

I'm not saying interfaces are bad.  I'm saying that I don't think the 
placement of documentation should be dependent on the rare cases where 
there are only header files.  I mean, I'm not for consistency just for 
consistency's sake.

  - Marius