Enable all gameobjects in list [Solved]

Right, so the long and short of it is that I am making a generic script that enables disabled gameobjects from a list that I just fill in my editor. Quite easy.

So, I got this

Code (CSharp):

1. public List <GameObject> EnableThese = new List<int>();

Now all I need, I think, is a way for it to enable all the gameobjects in this EnableThis list.
But I am a little stumped how to make that happen. Any advice?

And correct me if I am using lists wrong here.

 

Just iterate through the collection and call SetActive on each item.

Code (CSharp):

1. [SerializeField]
2. private List<GameObject> objects;
3.  
4. public void ActivateObjects()
5. {
6.    foreach (var obj in objects)
7.       obj.SetActive(true);
8. }

 

Not to be a syntax nazi, but for someone so new to scripting I feel you should be encouraging Typed variables and full brackets. Those are some annoying gotchas to those who don't know what they imply.

Also the private field with SerializeField attribute is another level of complexity that probably isn't necessary here, and raises even more questions to someone so new.

This is clean and easy to digest:

Code (CSharp):

1. public List<GameObject> objects;
2.  
3. // called by Unity when the game starts
4. private void Start()
5. {
6.     foreach (GameObject obj in objects)
7.     {
8.         obj.SetActive(true);
9.     }
10. }

By the way @Littlenorwegian , this:

won't compile. Your list variable is type GameObject, but you assigned it a list of type Int. Those types gotta match. But since you're filling the list in the Inspector, you don't need to assign a new list in code at all.

 

Brilliant, SirNiklas. Works exactly how I wanted.
And thanks to jeffreyschoch too. Looks cleaner. Doing a bit of learning by doing, slowly, so I am glad to know the best practices.

And yeah, I attempted to assign an int believing you needed that to note the amount of gameobjects in the list, heh.

 

@jeffreyschoch My additions do not make the code more difficult. It just encourages to read into the best practices, which as Littlenorwegian already wrote seems to be in his interest.

I added the SerializeField-attribute because I made the objects field ("private List<GameObject> objects") private. Because of this attribute Unity can still show you the variable in the inspector so that you can add game objects to the list, although the field is invisible to external classes.
The objects-field has become private because every member (methods and fields) of a type should only be accessible to the very least level possible. In conclusion, this objects list will certainly only be used from the class you declared it in, which means only this class should be able to access and work with it.

 

@SirNiklas I agree that it's good practice and I do that myself. I still think it's bad to throw all that at someone who is only asking how to loop through a collection. Gotta crawl before you walk.

I do feel that using 'var' in C# and omitting braces is bad practice though. Being explicit is the name of the game.

That being said, it's just my opinion, and Littlenorwegian appreciated the extra info so no harm done.

 

@jeffreyschoch Both var and leaving out braces is rather a choice of style and might only be unfitting for beginners, doesnt mean they shouldnt learn about it.

Above you wrote that "typed variables" should be encouraged, which var actually is. This keyword is syntax sugar and only makes declarations shorter and more readable.

 

@SirNiklas var is strongly typed, but implicit, and there's no way to know what type of variable it is without also knowing other things about the context, which makes it less readable.

Leaving out braces is an easy way to accidentally make logical errors due to the nature of one-liner code blocks, especially for beginners. It's good practice to be as explicit as possible, and imo there's really no good reason not to use full braces in every case.

I didn't mean to spark a debate about this. So I can agree to disagree if you have further rebuttals.

 

If this is a well-moderated forum the mods will remove this debate anyways as its off-topic.

Now I dont really care about the braces, thats just personal preference but the var keyword has some pros that make it foolish to ignore this feature.
To explain the argument of readability, think of a longer type name. For example List<GameObject> which in method blocks can be replaced by three letters which simplifies the code by a lot.
You said that a person working on a method using var has now way of knowing the variable's type, the developer could just hover over the identifier to reveal it or simply look at the assigned variable.

In the end its about the team working on the code, I just wanted to explain my reasoning about this matter.

 

If it were a type name, you could read it without needing to do anything, hence "readability". Everything you need to know is right there, no interpretation or searching needed. Using it causes an extra step for anyone reading your code, whether that be in visual studio or in plain text format thru git for a code review or otherwise.

The only time I would personally accept the use of "var" in a review is when the type is obvious, such as variable initialization where the type is defined on the same line anyway like this:

Code (CSharp):

1. var list = new List<GameObject>();

In that context, it actually does shorten the code at no loss of readability. For most other contexts, use of "var" obfuscates type and often intent as well. Using it as a local variable in a loop is not clear what the collection type is.

 

You make it sound like the developer working with the related code snippet has to go around the world to find out the type of the used variable. That is not true, I already stated how easy it is nowadays to reveal the type, moreover that isnt even necessary if the identifier has a well-thought name that indicates context.

The DRY acronym is a central principle of object oriented programming and the var keyword helps to stay true to it in every way.