Doing a search around I've found this kind of question being asked in the past but not targeted at VS2010 or C# .Net 4. Has anyone come across a way to make interface comments inherit through to the implementation classes for intellisense to use?
A colleague suggested copy and paste into the implementation but there must be a better way. Looking at the previous question recommendations Sandcastle appears to be a documentation generator which isn't what I need.
Consider the following:
public interface IFoo
{
/// <summary>
/// Comment comment comment
/// </summary>
string Bar { get; set; }
}
public class Foo : IFoo
{
public string Bar { get; set; }
}
public class Test
{
public Test()
{
IFoo foo1 = new Foo();
foo1.Bar = "Intellisense comments work";
Foo foo2 = new Foo();
foo2.Bar = "Intellisense comments don't work";
}
}
Is there a way to make intellisense on foo2 work?
It can't be done automatically without changing the IntelliSense in VS.
A colleague of mine uses ReSharper (http://www.jetbrains.com/resharper/) and I asked him to try out your code - and it does do exactly what you're asking for as it extends the intellisense of VS. You might want to look into that.
However, for me the simplest way to achieve this is the free version of GhostDoc - http://submain.com/products/ghostdoc.aspx which makes bringing in the base documentation of a method/property a single key combination.
The downside being that it's cloning the documentation, therefore if that base documentation changes you have to remember to go and clear it on the derived class/interface and re-generate it.
The ReSharper solution, of course, does not suffer from this problem, so you pays your money (literally, in the case of ReSharper) and takes your choice. There might be other free plugins that achieve this, of course.
Related
According to the MassTransit creators, having class-based inheritance is not considered as good practice - https://masstransittemp.readthedocs.io/en/latest/overview/inheritance.html
I honestly can't understand why. Here is my simplified real-life scenario: Imagine I have an insurance microservice which is dealing with policies. I know in advance that all the policy-related events are going to have some mandatory fields like: id, product, etc.
public class InsurancePolicyEvent
{
Guid EventId { get; set;}
Guid PolicyId { get; set; }
InsuranceProduct Product { get; set;}
}
Why can't I simply leverage inheritance here and do not repeat my self in the inherited events, like this:
public class PolicyTerminated : InsurancePolicyEvent
{
...
}
public class PolicyIssued : InsurancePolicyEvent
{
...
}
To clarify my position, MassTransit recommends the use of interfaces instead of classes, and is perfectly happy with a base type like you've shown above, particularly when it's to enforce fields as a type of event.
Interface-based inheritance is OK, don't be afraid, but don't go nuts.
And right below that, yes, class-based inheritance is discouraged - mainly because developers often do bad things with it. Now, what you've shown above is fine, I see no issues with it.
However, once your InsuranceProduct class starts to evolve, and some expectation of base-class virtual method dispatch behavior begins to creep into the model, that's the path to bad times. And it might not be you, it might be a less experienced developer who was taught OO class design and figured, why not right?
So, just be careful out there :)
I want to write a Visual Studio snippet which allows me to quickly create a class of the form:
public SomeClass
{
public SomeType SomeProperty { get; private set; }
public SomeClass(SomeType someProperty) { SomeProperty = someProperty; }
}
I want the parameter on the constructor to have the same name as the property, but lower-cased. I don't want to have to type the name twice. How do I do this?
I've already looked at the XML for snippets and I discovered that there are certain functions that can be used. For example, the built-in "switch" code snippet contains the following instruction:
<Function>GenerateSwitchCases($expression$)</Function>
According to this MSDN documentation page, there are three built-in functions that you can use in this <Function> tag. Unfortunately, neither of them does what I want (lower-case the first letter). Is it possible to define a function that I can then use in my snippet?
No this is not possible in Visual Studio today. The definition and execution of snippet functions is directly controlled by the C# language service. It is not currently an extensibility point. It is being considered for a future version of the product though.
When you add a new method to a class where do you put it? At the end of the class...the top? Do you organize methods into specific groupings? Sorted alphabetically?
Just looking for general practices in keeping class methods organized.
Update When grouped where do you add the new method in the group? Just tack on the end or do you use some sort of sub-grouping, sorting?
Update 2 Mmmm...guess the question isn't as clear as I thought. I'm not really looking for class organization. I'm specifically interested in adding a new method to an existing class. For example:
public class Attendant
{
public void GetDrinks(){}
public void WelcomeGuests(){}
public void PickUpTrask(){}
public void StrapIn(){}
}
Now we're going to add a new method PrepareForCrash(). Where does it go? At the top of the list, bottom, alphabetically or near the StrapIn() method since it's related.
Near "StrapIn" because it's related. That way if you refactor later, all related code is nearby.
Most code editors allow you to browse method names alphabetically in another pane, so organizing your code functionally makes sense within the actual code itself. Group functional methods together, makes life easier when navigating through the class.
For goodness sake, not alphabetically!
I tend to group my functions in the order I expect them to be called during the life of the object, so that a top to bottom read of the header file tends to explain the operation of the class.
I think it's a personal choice.
However I like to organise my classes as such.
public class classname
{
<member variables>
<constructors>
<destructor>
<public methods>
<protected methods>
<private methods>
}
The reason for this is as such.
Member variables at the top
To see what member variables exist and if they are initialised.
Constructors
To see if the member variables are setup/initialised as well as what are all the construction options for the class.
Destructor
To see the how the class is cleaned up and verify it with the constructors and member variables.
Public methods
To see what are the available contracts callers of the object can use.
Protected methods
To see what inherited classes would be using.
Private methods
As it's information about the internals of the class if you needed to know about the internals you can just scroll straight to the end quickly. But to know the interface for the class it's all at the start.
UPDATE - Based on OP's update
Logically a good way would be to organise the methods by categories of what they do.
This way you get the readabilty of categorising your methods as well as the alphabetical search from you IDE (provided this is in your IDE).
However in a practical sense I think placing the methods at the end of that section is the best way. It would be quite hard to continually police where each method goes, as it's subjective, for every method if the code is shared by more than yourself.
If you were to make this a standard it'd be quite hard to provide the boundaries for where to put each method.
What I like about C# and VB.net is the ability to use #region tags, so generally my classes look like this
class MyClass
{
#region Constructors
public MyClass()
{
}
public MyClass(int x)
{
_x = x;
}
#endregion
#region Members
private int _x;
#endregion
#region methods
public void DoSomething()
{
}
#endregion
#region Properties
public int Y {get; private set;}
#endregion
}
So basically You put similar things together so you can collapse everything to definition and get to your stuff really faster.
Generally, it depends on the existing grouping; if there's an existing grouping that the new method fits into, I'll put it there. For example, if there's a grouping of operators, I'll put the new method with the operators if it's an operator.
Of course, if there is no good grouping, adding a method may suggest a new grouping; I treat that as an opportunity for refactoring, and try to regroup the existing operators where reasonable.
I organize all methods into regions like public methods, private methods or sometimes by features like Saving methods, etc..
IMHO:
If you organize your methods alphabetically, put a new one depends on its name. Otherwise put it at the bottom of related group. This helps to know, what method is newer. The bigger problem is how to organize methods in groups, e.g. depend on what properties, but this is more individual for everyone and depends on a specific class.
When adding a web reference in Visual Studio 2005, I've noticed that every element within the wdsl is duplicated. E.g. for element ItemOne, the interface it generates contains both ItemOne and itemOneField. Both are the same thing, but one is a member and the other is a field. I suspect the field is just a getter for the member.
I can imagine using a field instead of a member for this...but in that case my tendency would have been to make the member private, to avoid clutter. This, despite the fact that the normal motivation for making such a member private is to hide implementation details, which is obviously not applicable in this case.
I realize that changing this now would likely introduce compatibility issues, but I don't see why they did it this way the first time.
Do not point out that such a change would introduce compatibility issues with previous versions of VS. I am interested in the original reasoning behind this.
It's a property with a backing field. What's the problem? Were you expecting it to generate an automatic property? They didn't exist until recently. Why change what works, especially since ASMX (and WSDL.EXE) is pretty much dead technology.
"I am interested in the original reasoning behind this"
as everything past 3.0 framework, the only way to create properties were having a private variable and the property name
private string myItemField;
public string myItem() {
get {
return myItemField;
}
set {
myItemField = value;
}
}
but now, there is no need for it...
public string myItem { get; set; }
the thing is, that this last code is compiled as the original one at the top, even if it's easier to write, it is compiled in the same old way, you will end up with a private variable and a property.
Same thing happens when you add a Web Reference, it needs a variable to hold the "stuff" and then the method...
OK, having tried my first TDD attempt, it's time to reflect a little
and get some guidance, because it wasn't that successful for me.
The solution was partly being made with an existing framework, perhaps
making TDD less ideal. The part that seemed to give me the biggest
problem, was the interaction between the view and controller. I'll
give a few simple examples and hope that someone will tell me what I
can do better wrong.
Each view's interface inherits from a base interface, with these
members (there are more):
public interface IView
{
void ShowField(string fieldId)
void HideField(string fieldId)
void SetFieldVisibility(string fieldId, bool visible)
void DisableField(string fieldId)
void ShowValidationError(string fieldId)
...
}
The interface for a concrete view, would then add members for each
field like this
public interface IMyView : IView
{
string Name { get; set; }
string NameFieldID { get; }
...
}
What do you think of this? Is inheriting from a common interface a
good or bad idea?
One on the things that gave me trouble was, that first I used
ShowField and HideField and the found out I would rather use
SetFieldVisiblity. I didn't change the outcome of the method, but I
had to update my test, which I seem should be necessary. Is having
multiple methods doing the same thing, a bad thing? On one hand both
methods are handy for different cases, but they do clutter the
interface, making the interface more complex than it strictly have to be.
Would a design without a common interface be better? That would remove
the fieldID, I don't why, but I think the fieldID-thing smells, I
might be wrong.
I would only make the Show and Hide methods, when needed, that is if
they would be called by the controller. This would be a less generic
solution and require more code in the view, but the controller code
would be a bit more simple.
So a view interface might look like this:
public interface IMyView
{
void ShowName()
void HideName()
string Name { get; set; }
int Age { get; set; }
}
What do you want to test? Whether Show* will make an widget in the UI visible? What for?
My suggestion: Don't try to figure out if a framework is working correctly. It's a waste of time. The people who developed the framework should have done that, so you're duplicating their work.
Usually, you want to know if your code does the right thing. So if you want to know if you are calling the correct methods, create mockups:
public class SomeFrameworkMockup extends SomeFramework {
public boolean wasCalled;
public void methodToTest() {
wasCalled = true;
}
}
Build the UI using the mockups.
The second thing to test is whether your algorithms work. To do that, isolate them in simple helper objects where you can all every method easily and test them with various inputs.
Avoid the external framework during tests. It only confuses you. When you've built a working product, test that using your mouse. If you find any problems, get to the root of them and only then, start writing tests against the framework to make sure this bug doesn't appear again. But 90% of the time, these bugs will be in your code, too.
At the moment I don't really see the added value of the common interface.
I think a better solution would be to have some properties on the controller class: IsControlXYZVisible. You can then databind the visible property of the control to this property.
And your unit test will test the value of IsControlXYZVisible, which will be easier to acomplish.
I also don't understand why you say you had a bad experience with TDD. I think your application architecture needs more work.
Your question is a little bit obscure for me but the title itself calls for a link :
The Humble Dialog box
And when you ask if it(s bad to have two functions doing the same thing, I say "Yes it's bad".
If one is calling the other, what's the point of having two functions ?
If not, you have a code duplication, that is a bug waiting to sprout whenyou update one and not the other.
In fact there is a valid case where you have two nearly identical functions : one that check its arguments and one that does not but usually only one is public and the other private ...