Creating using-like commands in C# [closed] - c#

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 know that C# does not currently support this, so this is more of a meta-C# question. I have been thinking of what changes would be required in the language to allow us to create our own commands like while or using. I could create a method accepting an Action, like Task.Factory.StartNew(), but then I would need parentheses around the curly braces and the syntax would not look the same.
Would this essentially amount to allowing us to apply parameters outside of the parentheses?
i.e.
public void MyUsing (IDisposable disposable) Action body
{
try
{
body();
}
finally
{
disposable.Dispose();
}
}
Commands like for, switch and if would be even more complicated to create because of their syntax.

I recommend you to take a look at the Roslyn project (which is essentially an opensource C# compiler written in C#!)
They also have demos of how easy it is to add language features.
https://roslyn.codeplex.com/
However, take note that it is unlikely for your changes to be accepted unless you are working in the C# team. If you want to have code generated for you, you could take a look at PostSharp, it isn't the same thing as you were suggesting, but it might suit you situation anyway.
http://www.postsharp.net/
PostSharp allows you to mark methods, properties, classes etc. with Attributes which will then trigger user defined code generation functions which will run after the initial compile process. It helps in situations where you don't want to copy paste the same code pattern over and over again.

Related

When do I split up classes into different scripts? [closed]

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 3 years ago.
Improve this question
I have been working on a project in Unity, and was trying to figure out how to abbreviate a large number into a more readable format. I found somebody who asked the same question and got some code, but the person who gave that code had 2 classes in the same C# script. I am new to Unity and C# in general, so this was not something I had seen before.
What I would like to know is when to put classes in different scripts, when to put multiple classes in the same script, and if I do put multiple classes in the same script how that affects that script and other scripts in the project.
From a C# logical point of view, it does not matter where a class is. From the practical perspective, it is usual to put every type (class, struct) in its own code file. I often make an exception for enums and put enums belonging to the same realm into the same file, e.g. things like DisplayStyle, SortOrder, Visibilty could be in a file named AppearanceEnums.cs. Enums are mostly small and don't contain logic.
for Unity, see: How to architect code as your project scales

How split a big method to smaller several methods in C# [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
How can I optimally split one big, difficult method to several smaller methods in C#? Is there any perception or functionality for this issue?
Assuming you are using Visual Studio to edit your C# code, there is built-in functionality for what you are trying to do: Extract Method Refactoring. Note that this is still a manual process - there is no automatic tool which knows how to take your entire method apart.
What to keep in mind while refactoring? Taken from Robert C. Martin's Clean Code:
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
Functions should do one thing. They should do it well. They should do it only.
We want the code to read like a top-down narrative.
Use descriptive names.
The ideal number of arguments for a function is
zero (niladic). Next comes one (monadic), followed
closely by two (dyadic). Three arguments (triadic)
should be avoided where possible. More than three
(polyadic) requires very special justification

Is #region really necessary in C# coding? [closed]

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.

Can I extend all objects (not just winforms control) in .Net to have a tag property? [closed]

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.

How come there's no C# equivalent of python's doctest feature? [closed]

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.

Categories