>  I'm not completely convinced by having the need of a specialized source
> editor in order to understand the source code better. If you ever need to
> develop the source in some environment where you don't have that editor
> with those fancy features, you are going to find yourself wading through
> thousands and thousands of lines of code.
>
>  Things like code block collapsing and code coloring are definitely
> helpful, but IMO good-quality code shouldn't rely on those editing 
> features
> in order to keep itself understandable and maintainable. You never know
> when you will have the need to understand the code in an environment
> which lacks those features.

Yes that's a good argument for not always using those features in general, 
but for me personally I don't think my C#.net/XNA code will ever be opened 
in anything other than the MS IDE :-)

Post a reply to this message

Warp wrote:
>   I'm not completely convinced by having the need of a specialized source
> editor in order to understand the source code better. 

You are perfectly welcome to write a second bit of source code and maintain 
it in sync with the main file when using C# also. ;-)

> If you ever need to
> develop the source in some environment where you don't have that editor
> with those fancy features, you are going to find yourself wading through
> thousands and thousands of lines of code.

It's really not a problem. I actually find it easier to find things in C# 
than in C++, exactly because I know where to look. If I want to see how 
alpha::beta is implemented, I know where to find it and I know what search 
string to put in. In C++, I'm lucky if I can figure out what header file 
it's in, let alone where in the class heirarchies it is.

That's one thing I'm finding about trying to figure out this huge 
undocumented code base I'm working with - it's almost impossible to actually 
track down where the f'ing code *is*. There's way too many things like

typedef enum {
   ... 300 lines of enums ...
} TYaddaBlow;

OK, now go grep thru half a million lines of code looking for that 
declaration to figure out what the possible values for the enum are. Don't 
forget that the same name is defined in three different layers of the 
architecture, so even when you find it, you need to read the 2000-character 
gcc line to try to figure out which .h file containing the declaration gets 
included first, so you know which enum definition that particular source 
file is using.  </rant>

>   Things like code block collapsing and code coloring are definitely
> helpful, but IMO good-quality code shouldn't rely on those editing features
> in order to keep itself understandable and maintainable. You never know
> when you will have the need to understand the code in an environment
> which lacks those features.

Then you generate the header docs from the source code and you're good to 
go. There's no reason to make maintaining two files a manual process. On the 
other hand, if you *want* to do so, you certainly can.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

scott wrote:
>> The only problem with code refactoring is that it really does have to 
>> recompile the code, which means it can't refactor code that doesn't 
>> compile. If you have a half-finished function you're typing in, and 
>> you realize you want to convert something in the middle of an earlier 
>> function into a stand-alone method, you have to clean up what you're 
>> working on enough to do that.
>>
>> Unless they've fixed that since last I looked.
> 
> They seem to have fixed that, I tried what you said and it worked fine.

Kewl. I remember reading someone's paper about how they figured out (for 
example) which brace you had intended to close in something with the wrong 
number of closing braces. It was a novel approach to incremental parsing.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Then you generate the header docs from the source code and you're good to 
> go.

  Not everything in a source file is supposed to be part of the public
interface.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Then you generate the header docs from the source code and you're good to 
>> go.
> 
>   Not everything in a source file is supposed to be part of the public
> interface.

Ah, but it *is*, in C++.[1]  In C#, you can tell it to leave the private 
functions out of the generated documentation altogether. :)


[1] Which, incidentally, I find highly annoying when it's time to add a 
helper function to a class to split up a big file, and I have to go declare 
this completely private class in a different file *and* recompile everything 
that uses the class, even tho I've just said "nobody outside the class is 
allowed to use this anyway."  But that's a minor annoyance, just part of the 
job, compared to the *CRAP* I'm dealing with lately in this code base. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

On Mon, 12 Oct 2009 18:50:12 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
>>    Not everything in a source file is supposed to be part of the
>> public interface.
>
> Ah, but it *is*, in C++.[1]

No.


> In C#, you can tell it to leave the private functions out of the
> generated documentation altogether.

There is no reason why a C++-capable version of "it" could not do the same.



-- 
FE

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Then you generate the header docs from the source code and you're good to 
> >> go.
> > 
> >   Not everything in a source file is supposed to be part of the public
> > interface.

> Ah, but it *is*, in C++.[1]

  What do you mean? Ever heard of the nameless namespace? Everything in
a nameless namespace is local to that source file and definitely not part
of the public interface of that module. (In fact, there's no way of
accessing anything inside a nameless namespace from another source file.)

  Also an inner class doesn't have to be declared in the public interface
(only its name has to be pre-declared, but that's not very helpful from
the outside).

  (In fact, even an inner class in the *public* interface of a class
doesn't have to be declared. It will work as a completely opaque type
from the outside in that case. I think this is an even more important
case where you *don't* want that inner class to become public, except
as an incomplete type, ie. "in type name only".)

>  In C#, you can tell it to leave the private 
> functions out of the generated documentation altogether. :)

  Btw, I really don't see a lot of difference between fancy source editor
features and a public interface generator. In both cases you need some fancy
external program to help you clarify the source code.

-- 
                                                          - Warp

Post a reply to this message

Fredrik Eriksson wrote:
> On Mon, 12 Oct 2009 18:50:12 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>    Not everything in a source file is supposed to be part of the
>>> public interface.
>>
>> Ah, but it *is*, in C++.[1]
> 
> No.

OK, I'll grant you that you were talking about the bodies of the functions 
also. My bad. :-)

>> In C#, you can tell it to leave the private functions out of the
>> generated documentation altogether.
> 
> There is no reason why a C++-capable version of "it" could not do the same.

Sure. But people are discussing .h files, where there's no such option in 
C++. In C, you could make the function static, but that's not the same thing 
for a C++ method.  Obviously you could write a tool that works almost as 
well for sufficiently well-organized C++ code as works for C#, but then 
you'd be complaining you might not have that tool elsewhere. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
>   What do you mean? Ever heard of the nameless namespace? Everything in
> a nameless namespace is local to that source file and definitely not part
> of the public interface of that module. (In fact, there's no way of
> accessing anything inside a nameless namespace from another source file.)

You can't make a private method on a class without exposing that in the 
header, can you?  (If so, I've been doing it wrong. :-)

>   Also an inner class doesn't have to be declared in the public interface
> (only its name has to be pre-declared, but that's not very helpful from
> the outside).

You're still exposing its existance in the header file, meaning you get to 
recompile stuff, for example. 0

>   Btw, I really don't see a lot of difference between fancy source editor
> features and a public interface generator. In both cases you need some fancy
> external program to help you clarify the source code.

You don't need such a tool in C# any more than you need a tool to generate 
the .h files for you in C++.

However, since C# makes the "makefile" structure part of the language, it's 
possible to write tools that extract equivalent documentation from C# that 
you can't as easily write in a portable way for C++.  I.e., even if you have 
a complete C++ parser, now you need a whole lot of extra stuff to understand 
*which* header files go with *which* source files when you're trying to 
parse C++.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   What do you mean? Ever heard of the nameless namespace? Everything in
> > a nameless namespace is local to that source file and definitely not part
> > of the public interface of that module. (In fact, there's no way of
> > accessing anything inside a nameless namespace from another source file.)

> You can't make a private method on a class without exposing that in the 
> header, can you?  (If so, I've been doing it wrong. :-)

  That's your argument for dismissing all the private types, functions and
data that can be specified in a source file (and which don't belong to the
header file)?

> >   Also an inner class doesn't have to be declared in the public interface
> > (only its name has to be pre-declared, but that's not very helpful from
> > the outside).

> You're still exposing its existance in the header file, meaning you get to 
> recompile stuff, for example. 0

  I don't understand that sentence.

> However, since C# makes the "makefile" structure part of the language, it's 
> possible to write tools that extract equivalent documentation from C# that 
> you can't as easily write in a portable way for C++.  I.e., even if you have 
> a complete C++ parser, now you need a whole lot of extra stuff to understand 
> *which* header files go with *which* source files when you're trying to 
> parse C++.

  I'm not completely following what you are saying.

-- 
                                                          - Warp

Post a reply to this message