4

Let's say that I have a Visual Studio project that needs to make use of a binary search tree data structure. Since .NET does not have a built-in BST data structure I will have to add the classes myself (like from this article). This will involve several classes: Node, NodeList, BinaryTree, etc....so my question is would it be better to add all these classes to one .cs file i.e. nest them, or should each class be it's own separate file? It seems a bit cleaner and possibly easier to reuse the classes if they are all together in one file, no?

I'm just trying to understand best practices for organizing and designing projects. Any advice or direction you could point me would be appreciated.

skaffman
  • 398,947
  • 96
  • 818
  • 769
BrazenTongue
  • 179
  • 1
  • 9

7 Answers7

3

The easiest way to use binary trees would be to download and reference the C5 Collections Library. Why reinvent the wheel?

That being said, the general rule is 1 widget --class/enum/struct/whatever -- per source file. A good practice (YMMV) is to [generally] have the filesystem hierarchy reflect the namespace hierarchy and assemblies should be named to reflect the namespace they contain.

Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • I think what the OP means is that we should consider the BST related files as only an example of a separated domain/library. Still, good point. – rsenna Jan 25 '11 at 20:08
  • 1
    Yeah, I should have clarified not to focus on the BST data structure. I don't actually need to use one, it's just a hypothetical to illustrate the question of how to handle related/dependent classes. – BrazenTongue Jan 25 '11 at 20:11
2

I recommend using one file per type. There's no economy in restricting the number of files and one file per type really helps with finding a type in your solution.

Quite often, files are organised in folders to help with levels of organisation (the folders are often named along namespace lines as these provide natural groupings of your types) although that is not always done.

Jeff Yates
  • 61,417
  • 20
  • 137
  • 189
  • 4
    The 1-type-per-file rule also helps prevent change collisions when multiple developers are working on a project. We hates resolving conflicts in source control. – Nicholas Carey Jan 25 '11 at 20:05
1

I would recommend to use some of the built-in structures. I doubt you really need binary tree.

If you write your own classes then each class should normally be in its own file. Use inner classes whenever you don't need to use them externally. (Make them private.) Inner classes are usually defined in the same file as the outer one.

Al Kepp
  • 5,831
  • 2
  • 28
  • 48
1

Like Jeff Yates, I would use one file per type. Java enforces that, .NET not - but this seems the way to go for well organized solutions.

Also, I would place all BST related files in a separated project in the same solution. If I understood you correctly, your application is not about BST's, it just uses them, right? If that's the case, a separated project is the way to go here.

And make well-named and well-defined namespaces too. Like MyApplication.Bst for BST related files, and MyApplication.UI for the front-end, for instance.

rsenna
  • 11,775
  • 1
  • 54
  • 60
0

I would create a folder under the project named BinarySearch and put them there.

JohnOpincar
  • 5,620
  • 3
  • 35
  • 38
0

I think putting multiple classes into a single file often makes the project unwieldy. There's no performance benefit. If there are an extremely large number of classes that can be grouped, do so with a directory structure.

Brett McCann
  • 2,469
  • 2
  • 27
  • 44
0

This question looks a whole lot like other onen already in stackoverflow:

The standard practice is to have one class per file, one notable exception being enums, delegates and others.

Community
  • 1
  • 1
Diogo
  • 1