The generic list class show lots of more or less useless information in debugger, like _syncRoot, Capacity and so on. Even the _items field is a little bit annoying.
Is there a way to get debug information that is as smart as usual? Or is something comparable to DebuggerDisplay attribute for build-in classes?
The List<> class already has a visualizer:
Not sure why you don't see it, you'd have to select the Raw view to see private members. Which is, well, raw.
You need to uncheck this option: Tools | Options | Debugging | General | Show raw structure of objects in variables window. Once unchecked you will get the visualizer for the List<>.
Related
I'm new to Go, and I'd like to know if there's a way in Goland or w/ a CLI tool to list all the types that implement a given interface.
I found a tool called guru that can list all interfaces implemented by a given type, but I haven't been able to make it work in CLI.
You can use Navigate | Declaration or Navigate | Implementation(s) on any type/interface and you'll see a list of interfaces implemented by a type or of types implementing an interface.
You can also use the green buttons on the IDE left side next to their type definitions to perform the same actions.
I like intellisense and I think everyone should always add structured comments on classes and methods, I say so because the concept of being "self commenting code" is per se a wrong practice.
How do you draw the line between something that for the creator is obvious but this isn't true for any other developer?
In my company we have a wide range of very useful shared NuGet packages, but most of them have no comments, or at least in the interfaces. This cause the consumer class, using IoC, to blindly use the interfaces loosing completely the comments and therefore the intellisense.
Maybe I don't create the NuGet packages in the right way, but so far the best practice I found, is to add comments in the interfaces and add in the implementing class, the comment: /// <inerithdoc cref=""/>.
This helps me share the documentation, parameters and return type descriptions and so on.
Now the inherithdoc, is mostly used for the XML documentation generation, but not really helpful when it comes to access the description from the implementation class.
An example, I have IMyClass with all the nice comments, if I open MyClass which implements IMyClass, I can read through the code but I don't have straight access to the comments and it is very annoying to be forced to jump back and forth to the Interface in order to read them.
So a possible solution would be to copy the comments across Interfaces and implementing Classes, but I hate duplication, and you can easily end up updating the descriptions here but not there.
So my question for the community is, how do you handle this? Is there Any extension that shows me the description maybe as part of the codelens?
Hovering the mouse on the cref attribute, allow me to get the description of the class/interface and methods, but not parameters.
We're looking for a way to document Core Data entities. So far the only real options I've come up with are:
Document externally using UML or some other standard
Create NSManagedObject subclasses for every entity and use code comments
Use the User Info dictionary to create a key value pair that holds a string comment
Option 1 feels like too much extra work and something that will almost certainly be out of date 99% of the time.
Option 2 feels natural and more correct than option 1. The biggest con here is that those comments could potentially be lost if this model class is regenerated using Xcode.
Option 3 feels a little less correct than option 2, but has the added advantage of adding automation possibilities with regards to meta data extraction. For instance, in one of our apps we need to keep a real close eye on what we're storing locally on the device as well as syncing to iCloud. Using the user info dictionary it's pretty easy to automate the creation of some form of artefact which can be checked both internally and externally (by the client) for compliance
So my question is whether it would be inappropriate to use the user info dictionary for this purpose? And are there any other options I'm missing?
Option 2 is what I use every time. If you look at your core data model (something.xcdatamodeld or something.xcdatamodel) you will see something like the picture below.
You can tie your entity to whatever class you want and then put the comments in there. It helps if you keep your entity name the same as your class name to make it obvious what you've done.
Additionally this also gives you the ability to add automation. You can do this by creating custom getters and setters (accessor methods) and a custom description method.
I use option 2 and categories. I'll let XCode generate the NSManagedObject subclasses and use a categorie on each of these subclasses. With the categories I do not loose my changes made in the categories, can document, make custom getter and setters and I am still able to use generated subclasses.
If we speak only about documenting (i.e. writing more or less large amounts of text which is intended to be read by humans) your classes, I'd use the option 2.
If you are concerned with the possibility of Xcode overwriting your classes in the option 2, you may consider creating two classes for each entity: one which is generated by Xcode and always could be replaced (you generally do not touch this file) and one other which inherits from the generated one and in which you put all your customizations and comments.
This two-class approach is proposed by the mogenerator.
Although if you need to store some metadata with the entities which will be processed programmatically, the userInfo is perfectly suitable for this.
I'm trying to find out what my choices are when I'm going to use user (persistent) settings.
In vs Studio this is possible in the properties of your project but I'm getting to know the limits there:
Only values are allowed that can be converted to string.
Collections (e.g items in a Listbox, with a name and value) cannot be saved.
What I would like to know, how do you implement user settings with collections, and how do you make user settings?
Emerion
If I understand correctly I think you're probably looking for serialization, and since you mention values that can't be converted to string I assume that you'd probably want binary serialization.
The System.Runtime.Serialization namespace contains classes to help you with this and here's an article that might be useful: Serialization in the .NET Framework
0 What's the difference between the following?
public class MyClass
{
public bool MyProperty;
}
public class MyClass
{
public bool MyProperty { get; set; }
}
Is it just semantics?
Fields and properties have many differences other than semantic.
Properties can be overridden to provide different implementations in descendants.
Properties can help alleviate versioning problems. I.e. Changing a field to a property in a library requires a recompile of anything depending on that library.
Properties can have different accessibility for the getter and setter.
"Just semantics" always seems like a contradiction in terms to me. Yes, it changes the meaning of the code. No, that's not something I'd use the word "just" about.
The first class has a public field. The second class has a public property, backed by a private field. They're not the same thing:
If you later change the implementation of the property, you maintain binary compatibility. If you change the field to a property, you lose both binary and source compatibility.
Fields aren't seen by data-binding; properties are
Field access can't be breakpointed in managed code (AFAIK)
Exposing a field exposes the implementation of your type - exposing a property just talks about the contract of your type.
See my article about the goodness of properties for slightly more detail on this.
In that case, yes it is mostly semantics. It makes a difference for reflection and so forth.
However, if you want to make a change so that when MyProperty is set you fire an event for example you can easily modify the latter to do that. The former you can't. You can also specify the latter in an interface.
As there is so little difference but several potential advantages to going down the property route, I figure that you should always go down the property route.
The first one is just a public field, the second one is a so-called automatic property. Automatic properties are changed to regular properties with a backing field by the C# compiler.
Public fields and properties are equal in C# syntax, but they are different in IL (read this on a German forum recently, can't give you the source, sorry).
Matthias
The biggest difference is that you can add access modifiers to properties, for example like this
public class MyClass
{
public bool MyProperty { get; protected set; }
}
For access to the CLR fields and properties are different too. So if you have a field and you want to change it to a property later (for example when you want to add code to the setter) the interface will change, you will need to recompile all code accessing that field. With an Autoproperty you don't have this problem.
I am assuming you are not writing code that will be called by 3rd party developers that can’t recompile their code when you change your code. (E.g. that you don’t work for Microsoft writing the .Net framework it’s self, or DevExpress writing a control toolkip). Remember that Microsoft’s .NET framework coding standard is for the people writing the framework and tries to avoid a lot of problems that are not even issues if you are not writing a framework for use of 3rd party developers.
The 2nd case the defined a propriety, the only true advantage of doing is that that data binding does not work with fields. There is however a big political advantage in using proprieties, you get a lot less invalid complaints from other developers that look at your code.
All the other advantages for proprieties (that are well explained in the other answers to your questions) are not of interest to you at present, as any programmer using your code can change the field to a propriety later if need be and just recompile your solution.
However you are not likely to get stacked for using proprieties, so you make as well always use public proprieties rather the fields.