C# style question

[Cogman]

So, I'm somewhat of a C# beginner. My question is this,

In c++ when you have a class, convention is to declare the class in a header and implement the functions in some other file, ie

header

class someClass
{
   private:
      string bob;
   public:
      void doStuff();
};

Implementation

void someClass::doStuff()
{
   bob = "frank";
}

Is there a similar convention in C#? While just browsing through code, it look like the common thing to do is to have the implementation be the definition, IE

public class someClass
{
   private bob;
   public void doStuff()
   {
      bob = "frank";
   }
}

This sort of just feels wrong as I'm just so use to breaking the two apart. I'm I nuts or is this just convention?

 

[NP Complete]

That's the correct way to do it in C#. Implementation and declaration in the same file.

The philosophy behind this is that the assembly (in C# and assembly is a dll or exe) holds all the execution and declaration information. When you want to reference code in another assembly, just add the reference to your C# project in visual studio, and you should be able to browse over all the public methods/classes.

If you want to reference a non-C# dll, you can try running the tlbimp tool on it, and it will create a C# wrapper dll to allow you to call into the dll. You can then add the wrapper DLL as a reference to your project, and call the functions as you would C# functions in another assembly.

 

[Hmongkeysauce]

Take a look at the "partial" keyword modifier for C#. It allows you to split up the definition of a single class over multiple files.

Your example class could be:

public partial class someClass
{
   private bob;
}

public partial class someClass
{
   public void doStuff()
   {
      bob = "frank";
   }
}

 

[Crusty]

One class per file, unless nested. If you need to 'define' your class before implementing it use a public interface in it's own file.

 

[Cogman]

One class per file, unless nested. If you need to 'define' your class before implementing it use a public interface in it's own file.

Well, it isn't so much a need as a preference. I like the ability to see a total definition of all the functions of a class quickly without having to see the code behind it.

 

[DaveSimmons]

> Well, it isn't so much a need as a preference. I like the ability to see a total definition of all the functions of a class quickly without having to see the code behind it.

Yeah, we have one web service class with over 40,000 lines of code. In C++ the header file is ~500 lines which is much easier to read.

 

[Crusty]

Well, it isn't so much a need as a preference. I like the ability to see a total definition of all the functions of a class quickly without having to see the code behind it.

That's what Visual Studio is for, the object browser or class view will show that level of detail.

If you're not using VS, then you can always declare an interface and have your class implement it. Then you can just look at the interface file to see your entire class definition.

 

[Scooby Doo]

You can also use the #region to collapse the code.

 

[tatteredpotato]

You're stuck with using a public interface if you want to see a list of the functions straight up, but VS does a good job collapsing code. If you collapse all you should just see a list of functions.

I actually learned C# before C/C++, so when I started getting into C/C++ I found the header file concept very confusing and redundant. We all like what we learn first I guess.

 

[linkgoron]

ctrl m+o is your friend.

but ,if you're still unhappy there is a solution for your problem. Sort of.
as stated before in this thread your best bet is using partial classes.
You can also create partial methods (linq2Sql uses this feature for creating custom validation).


more on partial classes:
http://msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx

and partial methods:
http://blogs.msdn.com/b/charlie/archive/2007/11/11/partial-methods.aspx

 

[Cogman]

🙂 I think I'm going to have to read up on all of VS's hotkeys. There are so many.

 

[linkgoron]

🙂 I think I'm going to have to read up on all of VS's hotkeys. There are so many.

I'd say Ctrl M/O , Ctrl K/D (I call it the Javascript compiler) are the most useful for writing code.
I've seen people use ctrl+tab, but it doesn't work well with me.

 

[tatteredpotato]

I'm going to throw this C# question here as opposed to starting a new thread:

What exactly is the default namespace? Does it get prepended (if that's even a word) to all the namespaces you declare? If I have a project I declare as having the default namespace Foo.Bar, and then create a class in that project, declaring it in

namespace Foo.Bar {
    public class A{
      ...
    }
}

Then to access it using the fully quallified name, I need to reference:

Foo.Bar.Foo.Bar.A

If this is the case, I'd like the default namespace to be an empty string, but that's not acceptable. I've never played around with the default property so I think I really confused myself by doing so. Whats the accepted style for assembly names and default namespaces?

 

[Cogman]

Namespace is a namespace (it is the same in c++)

As long as the name is the same, everything between the namespace brackets gets added to the same namespace as code written elsewhere. If you wanted to nest it like you showed, you would have to type in this.

namespace Foo
{
    namespace Bar
   {
      namespace Foo
      {
          namespace Bar
          { }
      }
   }
}

 

[Crusty]

I'm going to throw this C# question here as opposed to starting a new thread:

What exactly is the default namespace? Does it get prepended (if that's even a word) to all the namespaces you declare? If I have a project I declare as having the default namespace Foo.Bar, and then create a class in that project, declaring it in

namespace Foo.Bar {
    public class A{
      ...
    }
}

Then to access it using the fully quallified name, I need to reference:

Foo.Bar.Foo.Bar.A

If this is the case, I'd like the default namespace to be an empty string, but that's not acceptable. I've never played around with the default property so I think I really confused myself by doing so. Whats the accepted style for assembly names and default namespaces?

When you set the 'default namespace' in the project properties page that's the default namespace used when you create a new class/interface using the wizards. It does not prepend that to anything automatically, it's just used in the code generation tools to provide a namespace for the code.

 

[tatteredpotato]

When you set the 'default namespace' in the project properties page that's the default namespace used when you create a new class/interface using the wizards. It does not prepend that to anything automatically, it's just used in the code generation tools to provide a namespace for the code.

Hmm that's what I thought but my trials indicate otherwise. I think I've just looked at too much code today 😛

EDIT: AH HA! I just want to say screw VB and everything it stands for (or maybe I'm just a little frustrated at it ATM lol). In a C# project, the text box is "Default Namespace", and in a VB project it's a "Root Namespace". C# functions as Crusty describes, but VB actually does prepend the "Root Namespace" to whatever namespaces you declare. My solution has some VB projects and some C# project, and I assumed their properties boxes worked the same.

 

[Train]

...
This sort of just feels wrong as I'm just so use to breaking the two apart. I'm I nuts or is this just convention?

This is exactly what the partial keyword is for

public partial class MyClass
{
// blah blah
}

and in another file:

public partial class MyClass
{
// other blah blah
}

 

[nickbits]

This is exactly what the partial keyword is for

public partial class MyClass
{
// blah blah
}

and in another file:

public partial class MyClass
{
// other blah blah
}

Not really. You can split the code into multiple files but you can't split declaration and implementation as in c++.

 

[Train]

Not really. You can split the code into multiple files but you can't split declaration and implementation as in c++.

oh you mean like header files? .h files is something I always hated about C++

In that case then I guess he's just SOL, but a wise coder once told me, that when learning a new language, learn the style and quirks of the new language as they are, trying to shoehorn the new one into the style of your previous language is usually defeating the purpose of picking up a new one.

 

[linkgoron]

Not really. You can split the code into multiple files but you can't split declaration and implementation as in c++.

Yes you can. Partial methods do exactly that.
You declare a partial method in one file, and in the other you implement it.

I wouldn't do this. It's not what partial methods are for, but you can.

 

[tatteredpotato]

In that case then I guess he's just SOL, but a wise coder once told me, that when learning a new language, learn the style and quirks of the new language as they are, trying to shoehorn the new one into the style of your previous language is usually defeating the purpose of picking up a new one.

I've heard similar and it's probably good advice... If you just want an at-a-glance definition of the class, just collapse all the methods to the definitions via code folding.

 

[Scali]

The philosophy in .NET (and Java before it) is simply that a declaration is redundant.
Just write the implementation, and the compiler can derive the declaration for you. It's implicit in the implementation, so no need to explicitly define it.
There are no header files in .NET (or Java). Header files are specific to certain languages/frameworks, and the .NET framework is not one of those languages/frameworks.

 

[Train]

The philosophy in .NET (and Java before it) is simply that a declaration is redundant.
Just write the implementation, and the compiler can derive the declaration for you. It's implicit in the implementation, so no need to explicitly define it.
There are no header files in .NET (or Java). Header files are specific to certain languages/frameworks, and the .NET framework is not one of those languages/frameworks.

Another reason for separate header files, as explained to me, was that C++ compilers didnt always have the RAM available as compilers do now, here's a snip I took from another site:

30-40 years ago, compilers couldn't justify the cost of keeping the entire file in memory like a Java/C# compiler does. It had to scan the file sequentially, and so things had to be kept simple. Today, it's an awkward, error-prone and inefficient mechanism. But it made sense back then - jalf

I, for one, am glad we don't have to put up with header files in Java/C#. IMO, it just adds bloat.

 

[Cogman]

Another reason for separate header files, as explained to me, was that C++ compilers didnt always have the RAM available as compilers do now, here's a snip I took from another site:



I, for one, am glad we don't have to put up with header files in Java/C#. IMO, it just adds bloat.

The purpose of header files is to contain function prototypes. Thats really it. They can do other stuff, but generally it is just setting up a place holder for the compiler to say "Hey, this function/class exists somewhere else in the code, so don't freak out if I try to call a function you haven't seen yet."

 

[Scali]

I don't know the exact mechanics of modern .NET implementations in binary form, but I don't think they need to keep the entire file in memory.
There is probably some kind of 'precompiled header' stored in the assembly. They don't need to access the actual implementation in order to link other code to it, and extract type info etc.
Probably similar to COM objects and their interface definitions (type libraries).