Return to Answer

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item.

3. You can always get to a class or enum definition by right-clicking it and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are logically related, simply put them in their own folder in the Project Explorer.

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item referencing it.

3. You can always get to a class or enum definition by right-clicking the reference and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are logically related, simply put them in their own folder in the Project Explorer.

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item.

3. You can always get to a class or enum definition by right-clicking it and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are related, simply put them in their own folder in the Project Explorer.

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item.

3. You can always get to a class or enum definition by right-clicking it and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are logically related, simply put them in their own folder in the Project Explorer.

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item.

3. You can always get to a class or enum definition by right-clicking it and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are related, simply put them in their own folder in the Project Explorer.

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item.

3. You can always get to a class or enum definition by right-clicking it and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are related, simply put them in their own folder in the Project Explorer.