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
Related
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 1 year ago.
Improve this question
I am new to unity ( <200 hours) and I don't know what the proper practice is regarding when to create a new script vs. modify an old one.
For example:
My UI elements all share a script which has booleans for 'isSlider' and 'isButton', etc.
This toggle is used to activate or deactivate unique functions depending on the type of UI element while reusing some generic functions used across all of them.
Would it be better practice to create a new script for each UI element and just copy the generic code or is it okay to have toggleable functions to modify the functionality in the inspector.
Thanks for your help!
in OOP, you want to abstract functionality, rather than put it all under the same class
Look at the principle of single responsability: https://en.wikipedia.org/wiki/Single-responsibility_principle
it states that each class should be responsible for a single unit of functionality, therefore buttons and sliders should be different classes
if you have some generic it would make sense to share between all components, you can make your ui elements inherit of a parent class that handles that logic, for that, look at the concept of abstraction: https://www.guru99.com/java-data-abstraction.html
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 6 years ago.
Improve this question
I'm going to develop a C# windows application which hosts several tabs in one form. Since components inside each tab are complicated enough, having all codes stored in one file Form1.cs is make it hard to handle all methods and code snippets.
I want to know are there any good practices to manage code in such condition?
I have made Forms Applications like that before, and I know what you mean about the code getting cumbersome for the .cs file.
Assuming you're not doing this already:
What I would do is compartmentalize some of the methods and members to separate classes that you call when needed via access operators and/or references. If you find yourself reusing the same set of lines dozens of times, put it in a static method that you can call everywhere without having to declare class objects... Each Tab can call some kind of method like RunTab1(); that will access the appropriate objects, classes, members and so forth. This way, when you want to work on Tab2, you can go to that class and ruffle through there, instead of going through one GIANT file looking for one small thing.
I know that sounds like a bit of a generic answer, but I've done it and it worked for me for a multilingual translator among many other things. Even what I'm working on now - some of the files are over 30k lines and I don't get any lag at runtime. Hope that helps.
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
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 just am a bit confused regarding what is right and wrong or rather what is the recommeded practice.
I have a class file A.cs which contains an abstract class.
I want other classes which would be located in other Dlls to reference to this class.
Hence what is the recommended practice?
Do i create a dll which contains this class and other dll's would reference this dll.
Or do i include this class file in every dll so that references are set correct (considering all dll projects reference this cs file from same location)
What is the recommended practice? What are pros and cons of same?
Think of your Object Orientated design principles. SOLID and DRY.
Write it once and reuse it.
As for where the code resides i.e. in which assembly, it's really down to how you organise your code. Does this piece of code need to be used only by code in this assembly? Does it need to be shared with others?
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.