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

[Daniel B. <ba...@we...>]

On Sun, Mar 12, 2000 at 08:27:17AM -0800, Marius Sundbakken wrote:
> A rubber band selector may seem irrelevant at this stage, but I feel that 
> YOU have much of the design already figured out so I don't want to start 
> hacking away at something that has to be dumped anyway.  This way, a rubber 
> band selector isn't such a waste of time after all (we have to have it 
> anyway) :-)

Sounds like a good idea.  Personally I'm working on the relationship
lines right now.  I can now move around the ends of the lines, but I
can't get them to stick to another class.

> A pragmatic editor, such as Emacs, will of course do the "columnization" 
> for you. >:->

So why are you arguing about it, if it isn't a problem? ;)

> OK then, now at least the variables have a sane indention style...
> only the rest to go :-) Such as the current GNU indention:
> 
>   if
>         {
>         }
> 
> which is, of course, inferior to the ANSI indention:
> 
>   if
>   {
>   }
> 
> :-))

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;

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

> 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?  Reason: Always using
a clean Tab for indentation makes it easy to increase or decrease the
indentation level, such as when you're putting an if-statement around a
block of code, without having to use an intelligent editor that can
switch between spaces and tabs.  Also, tabsize 8 is too much.

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

> >For me it's a way of keeping apart the difference between the interface
> >and the documentation of _what_ the class does from the implementation
> >and _how_ and _why_ it does it.  The header file is the "contract" of
> >the class, and as such, is a good place to put the documentation.
> 
> This sounds good... in theory.  For example, now as I'm learning the code, 
> it would have been much easier to switch between the cpp files to get both 
> code and documentation, instead of switching between *double* the amount of 
> files.

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...

You could also try Vim, it's pretty good at switching between files. ;)

> 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.

> 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 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.  But it's an
interesting concept.

> >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.

On the other hand, as long as you write documented code that does nice
things, I'm happy. :)

/Basic