We Keep Coding

C#, .net, general programming architecture. GetType or Enum : Which is better? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Which do you think is better..
if (thing.GetType() == typeof(thisthing))
{
//do stuff for this type of thing.
}
Or give the objects an Enum property
if (thing.TypeName == NamesEnum.thisthing)
{
//do stuff for this type of thing.
}

Neither of these is a particularly extensible or maintainable approach.
It's typically better to design this directly into a virtual method in your type hierarchy, and just call the method. This allows other classes to override and provide custom functionality as appropriate.
In your case, the thisthing type (which should be named ThisThing if you want to follow .NET naming conventions) would just have a DoStuff method which could be virtual if needed, and call it.

It depends:
if (thing.TypeName == NamesEnum.thisthing)
will run more performant then GetType() as, this a simple comparison of 2 numeric values.
But:
if (thing.GetType() == typeof(thisthing))
is more more "flexible": when you do some refactoring, change type name or whatever, this condition will still work.
But will fail in condition, if 2 types belong to 2 different assemblies, instead in first case this still will be matched as equal,as you campare not types but just enum values.
In short, there is no best approach, just most suitable for your needs.

IF you are working with basic types that don't have sub types...
your first example can be shortened nicely to
if (thing is typeof(thisthing))
Depends on the situation really. If you get to a lot of different types you're going to want a switch statement at some point, so I would say option 2 if there are going to be a lot of types.

Would you make this method Static or not? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
During a code review I presented a method quickly to the team that I had made static and one person agreed that there was no reason for it to not be static and a person disagreed saying that he would not make it static because it wasn't necessary and just to be on the safe side for future modifications and testing.
So I did quite a bit of research and obviously it's a specialized case but I would like to know what you would do in this situation and why?
(Its basically a helper method I call from a few different methods, a very low traffic page. More for my knowledge and learning on Static.)
private IEnumerable<Category> GetCategoryByID(int id, Context context)
{
var categoryQuery = from selectAllProc in context.SelectAll_sp()
where selectAllProc.CategoryID == id
select selectAllProc;
return categoryQuery;
}

Making private methods static is a form of micro-optimization; the method call is slightly faster. But the difference is almost too small to be meaningful.
Generally speaking, you should mark a method static when it:
Doesn't interact in any way with instance members, and
You would like to have the ability to call it without instantiating the class, as in Class.Method()
Ordinarily, methods like your example would go into their own static helper class, if they are used in more than one place.

If I were you I would ask my self the following questions.
Is it something which is related to type or instance of type?
If the answer is yes, I would be slightly inclined to make it static else, make it non static.
If you can give us some more information, the community can come up with some good options.

The first remark that comes to my mind is that by declaring this method static and possibly using it in multiple places in your code you are introducing a Service-locator kind of dependency.
As far as I know the main problem with it is that implicit dependencies are introduced, i.e. they can't be inferred by looking at method signatures.
As a consequence it can be much harder to assess the impact of a modification of your static method on the rest of your system.

Extension methods and static methods mismatch prototype matching in c# [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Having encountered a more advanced collision problem of extension and static methods I exemplified and simplified some code to:
using System;
namespace Test
{
static class EM
{
public static string To(this object o)
{
return o.GetType().ToString();
}
}
class A
{
public static string To() { return "Test.A"; }
}
class B { }
class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
object o = null;
o.To();
B b = null;
b.To();
A a = null;
a.To();
A.To();
}
}
}
I got myself suprised when the .NET compilers, ranging from 3.x to 4.y failed to resolve which method should be called in the line where "a.To();" appears. Of course, I paraphrased the compiler but that's what the error message can be brought to (literally "Member 'Test.A.To()' cannot be accessed with an instance reference; qualify it with a type name instead").
I am posting this for not going into details of why the compiler alerts a programmer (already know the rules) but more to boost a discussion in what would be a near or final resolve to the problem of this certain kind (take into account inheritance) ahead of Microsoft, where a human can tell the extension/static method call matches easily, whereas the compiler even does not supply the exact programmer's mistake description or a hint.
Looking forward to hearing from 'stackoverflowers'.

First off, your "question" is explicitly a call for discussion. It will therefore be closed, because a call for discussion is not a question. StackOverflow is not a discussion site; there are any number of forums you can use to have a discussion. This is a good place to ask a question.
To clarify the situation: what is happening here is:
overload resolution is determining that the call a.To() has an applicable candidate in the form of the static method.
the fact that the method is static but the receiver is an instance does not make the candidate inapplicable. Rather, it makes it an error for overload resolution to choose it as the best applicable candidate.
Extension methods are not checked at all unless there was no applicable candidate. There was an applicable candidate, albeit an illegal one, so extension methods are not checked.
I agree that this is a bit weird, but the analysis is both correct and desirable. The language designers must decide what is more likely: that the caller intended to call the static method but mis-typed "a" for "A", or that the caller intended to call some completely different method that might extend some type compatible with "a". The safer assumption is the former, and therefore we give an error.
I understand that some people might find this analysis somewhat weird. It is somewhat weird, but it does make sense. If you think these rules are arcane and confusing, you're right; this is what happens when you bolt on new rules to an existing algorithm over a period of more than a decade.
Overload resolution in C# was originally designed to handle a very simple language; "params" was the most complicated part of overload resolution. it now must handle generics, type inference, extension methods, dynamic, and named and optional arguments. All those changes have severely stressed the overload resolution algorithm because every time a new feature is added we must ensure that the old features continue to work just the same.
Regarding your specific situation: if it hurts when you do that then do not do that. It is a very bad idea to make static, instance and extension methods that have the same name. They are unlikely to do the same thing, so do not make them have the same name.
the compiler even does not supply the exact programmer's mistake description or a hint.
Nonsense. The compiler tells you exactly what is wrong: overload resolution chose a static method, and you called it with an instance as the receiver. That's the error in the program, and that's the error that is reported.

Method lines amount. Clean code [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What is the optimal amount of lines in method shold be used?
Curly braces doesn't count.
What code is better? Code is runing in Main()
//1st
string line;
while ((line = Console.ReadLine()).ToLower() != Break)
{
commandAnalyzer.AnalyzeAndRun(line);
}
// or 2nd
RunTextualInterface(commandAnalyzer);
private static void RunTextualInterface(TextCommandAnalyzer commandAnalyzer)
{
while (notBreakCommand())
{
analyzeCommandWithHelpOf(commandAnalyzer);
}
}
private static void analyzeCommandWithHelpOf(TextCommandAnalyzer commandAnalyzer)
{
commandAnalyzer.AnalyzeAndRun(readNewLine());
}
private static bool notBreakCommand()
{
return readNewLine() != Break;
}
private static string readNewLine()
{
return Console.ReadLine().ToLower();
}
// result just the same
P.S I am asking cause out teacher said that every method must have maximum 6 lines.(Curly braces dosn't count)

I think first approach would be better in this case. Too many method will decrease the readability when the logic involved is not too complex and not that large that it should be a separate method. Also it will make sense to make different methods if this logic has to be used by other parts of program as well. But again as the methods are so small, it doesn't even makes sense to me to make a separate method in this case

You want to reduce the amount of code you need to maintain without reducing readability. I like your first answer. Read Steve Yegge on how code size is Code's Worst Enemy.
Strive to keep everything the reader of your code will need to understand your code as local as possible. Use abstractions (e.g. refactoring stuff to methods) where they help. Avoid abstractions (e.g. inventing new names for operations your reader is already familiar with) where they don't help.
As to the various rules on method sizes: They aren't rules. They are guidelines. Whenever your method gets too long, stop. It could be a sign of a bad design. But it doesn't have to be - use the rule to trigger a closer look at your code.
Develop a sense of style. This will change all the time as you progress. Don't be afraid to update your style all the time - though do try to keep the same style during a project. Try out different styles and gain experience. It is the only true path.

If you're interested in that kinda questions, I'd suggest reading:
Code Complete 2nd Edition
The book has a chapter about that:
"Creating high quality code" -> "How long can a routine be?"

Foo() vs this.Foo() [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have a co-worker who uses a C# refactoring tool. The tool for some reason perfers:
this.Foo()
over
Foo()
Now we've asked him to turn it off simply because it's annoying to have all the code re-written automatically, but that's not the point.
Am I missing something, or is this just wrong? Why on earth would I want this.Foo()?

As other answers here point out, this is largely a matter of style.
Many times a call to Foo() would be unambiguous without the this., but there are times where it might add clarity. For example:
EventHandler foo = GetEventHandlerFoo();
EventHandler baz = GetEventHandlerBar();
foo();
this.Bar();
baz();
In this case, the this. prefix helps to make the method invocation stand out from the delegate invocations.
Is this necessary? No, and Lasse V. Karlsen correctly points out that the this. is just a surrogate for a naming convention that makes it unambiguous.
But I find that I will frequently use the this.Foo prefix on local properties for a similar reason, where again it is more a matter of style.

If you want to use it, use it.
If you don't want to use it, don't use it.
There's no right answer here.
If for some reason you have a naming convention where the name alone isn't enough to determine whether you're looking at a local variable, a method parameter, an instance field, a property, or a method, you should fix the naming convention, instead of prefixing local fields with this. to distinguish them from local variables.

I think this comes down to a question of syntax vs. semantics. The argument for this.Foo() is it very explicitly denotes exactly what Foo() is and where it came from. There's no wondering if it was an argument passed in to a method, or a static class declared who-knows-where. It's a method on the current object, period. Anything less and you're giving up clear semantics in favor of tighter syntax.
The obvious argument against it: Mouse-over and ctrl+click.

It's a style thing. Sometimes people think it makes the code more clear -- apparently some people find it helpful to be explicit about the target of a method invocation. Personally, I find the spurious use of this to be distracting.

This example demonstrates how the this keyword can be used to explicitly describe a variable's scope:
class Item
{
int id;
public Item (int id)
{
this.id = id;
}
}

I always use this. since it explicitly shows where the thing is. I don't even use a refactoring tool to do it. I type it by hand.