![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Fredrik Eriksson
Subject: Re: Visual C# .net (and XNA) first impressions
Date: 12 Oct 2009 13:49:15
Message: <op.u1o7sdl37bxctx@e6600>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 12 Oct 2009 18:50:12 +0200, Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Fredrik Eriksson wrote:
> On Mon, 12 Oct 2009 18:50:12 +0200, Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |