Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm just curious if #region is really necessary in C# coding, because I don't think I really need it since I can keep track of everything I do(mostly because the projects are small).
So is it really necessary to learn at all?
Good and strong responses to why and why not are very welcome!
No, it isn't necessary and some would say that it isn't even useful.
Personally, I'll use regions if it makes sense to group functionality together - related unit tests, for instance is a place that I'll use regions - but I know that folks differ on this opinion.
The whole point with regions is that it is simply a convenience for collapsing an area of code. It doesn't enforce anything, doesn't check that you've not put functions in the wrong place, etc. But it can be helpful in certain circumstances.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I need to create an "if" statement but with a different name. Something that I could type instead of "if" but would work exact the same way.
I'm pretty sure you could do this in C and C++ by use of macros.
Such a usage could have looked something like this;
#define FagCelDev if
This is not available in C#. According to this source this was a decision made to help keep the language readable. I would suggest that they made a good decision. There is no good reason to do what you are proposing - it will just make your code less readable.
Doing things like this is a highly effective way to confuse yourself when you read your code in a year.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I know this is "technically" a duplicate of this question. Should I recommend sealing classes by default?
But I'm asking it again because apparently the recommendation has changed1 with the times though I can't find anything in the last few years about it or about the fact that more and more people are recommending AGAINST sealing classes now thanks to the improvements in testing (which was one of the main reasons), processor speed (speed difference now is negligible), etc.
I'm trying to find out what the latest guideline is for weather or not to mark classes as sealed.
1 Essential C# 6.0 (5th Edition), Mark Michaelis (co author Eric Lippert):
"In general, marking a class as sealed is rarely done and should be reserved
only for those situations in which there are strong reasons favoring
such a restriction. In fact, leaving types unsealed is increasingly desirable,
as unit testing has become prominent because of the need to support mock
(test double) object creation in place of real implementations."
This is hardcopy proof as the others are all word of mouth.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Assuming I was writing my own version of .Net :)
What would be the downside of such a setup?
Yes, I am talking about a new anti-pattern here to avoid creating endless tuples and EventArgs. I think such a setup would have made coding a lot cleaner.
No. The Tag property has history, it was important in VB6 and Winforms was meant to replace it. It needed to be added to make porting code relatively simple.
It is entirely unnecessary in .NET. It supports implementation inheritance, a feature that VB6 didn't have. So if you want to add extra properties then you just derive a class and add them. And you'll be able to give them a good name and a type so you don't have to cast every time you read the property. This works just as well with Winforms controls.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Can anyone tell me what would be more efficient: A large program is written in visual-C++ years ago is now intended to be written in C#. What would be better, re-writing the whole code of visual-C++ in C# or write C++ DLLs to be used in C# program via DLLimport?
I guess it depends on how data-centric your code is. If you can easily separate out the functionality that does not require an interface, then you'd most likely be better off writing a DLL to utilize this functionality, and then re-writing the interface in C#.
If the program is rather interface heavy, and you do not want to go through separating out all of the data functions, then I'd just go ahead and re-write the whole thing in C#, although I'd expect to lose some performance.
VisualC++ is still a very widely used language - is this your only reason for wanting to move to C# (i.e. finding it hard to recruit people, lacking skills to continue development)?
There is only a single answer to this: "it depends". We cannot possibly know this, it's something you must decide.
Check what you need in terms of time and other resources for both. Check what benefit your gain from both. Weigth cost against benefit. Decide.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Seems like it would be a good way to introduce some people to unit testing.
Well for one thing, the documentation for doctest talks about "interactive Python sessions". There's no equivalent of that in C#... so how would the output be represented? How would you perform all the necessary setup?
I dare say such a thing would be possible, but personally I think that at least for C#, it's clearer to have unit tests as unit tests, where you have all the benefits of the fact that you're writing code rather than comments. The code can be checked for syntactic correctness at compile-time, you have IntelliSense, syntax highlighting, debugger support etc.
If you're writing code, why not represent that as code? Admittedly it's reasonably common to include sample code in XML documentation, but that's rarely in the form of tests - and without an equivalent of an "interactive session" it would require an artificial construct to represent the output in a testable form.
I'm not saying this is a bad feature in Python - just that it's one which I don't believe maps over to C# particularly well. Languages have their own styles, and not every feature in language X will make sense in language Y.