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

Post a reply to this message

>  You can do pretty much the same thing in C++, by implementing the methods
> in the class declaration. Of course this is recommended only for small
> classes. With large classes you'll end up with a megaclass which will be
> hard to understand and maintain, so it will cause more trouble than it's
> worth.

Yes, this had always been my mentality with C++ too, in fact it was very 
rare I would put any actual code in the class declaration file.  With C# 
though it kind of forces you to do this (I don't know whether it's possible 
not to), which at first I thought was terrible, but once I got used to 
"collapsing" the code with the little +/- icons in the margin, I think it 
works really well.  You can have multiple levels of the collapse tree and 
define your own collapse regions in the code if you want (so if you had 
several methods implemented all relating to one part, you could collapse all 
these together).  The result is that the source file *looks* like simply the 
class declaration, but when you need to you can expand any part to see the 
actual code.

If I went back to using C++ for something, I might be tempted to do this 
too.  I wonder if the Visual C++ Express edition IDE is the same as the C# 
one?  Maybe I just have an old version of the C++ one that doesn't contain 
some of the newer features.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> which at first I thought was terrible, but once I got used to 
> "collapsing" the code with the little +/- icons in the margin, I think it 
> works really well.

  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.

-- 
                                                          - Warp

Post a reply to this message

"scott" <sco### [at] scottcom> wrote in message 
news:4acf4330$1@news.povray.org...
> [...]
> One little niggle I had to start with was that when you define a class, 
> you need to write the code for all the methods of that class in the 
> definition too (in C++ I would usually put the actual method code in a 
> separate file). [...]

In the .NET environment, you could do it that way by writing an interface, 
then implementing the interface in a class definition. I wouldn't recommend 
doing that just to make C# behave like C++, though. C# is great at what it 
does, and C++ is great at what it does, but they're really two different 
languages. C# is a front end for the .NET CLR, and is made so that C and C++ 
programmers have a familiar way in to that environment. C++ is for 
programming down to the bare metal, and hopefully always will be.

I use .NET languages when I need to quickly make input modules. You still 
can't beat C++ for performance, though. :)

Post a reply to this message

>  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