initialize data inventory in the inspector vs into a code?

Code (CSharp):

1. [System.Serializable]
2. public class Unit{
3. int id;
4. string name; // string type
5. ...
6. }
7. public class Main:MonoBehaviour{
8. public Unit[] unit;
9. }
10.  

suppose we want to initialize data(for examples units/weapons/items info), We can initialize them into a script or the inspector. which one of them is a standard procedure?
if we use the inspector in order to initialize then when I change fields names or class name etc(change name variable to type), I miss the information (values) and have to initialize again!

 

You are mixing terms. I'm a self learner, so I'm usually not picky about it, as I do too, but you need to learn some basic terms/vocabulary otherwise not much will make sense for you and people reading your questions. This also usually suggests that you don't really understand how those things work.

You don't initialize into a script or inspector. You can initialize objects from a script and set data from a script or through the inspector.
That aside, you can use both. Standard procedure depends on particular case, so in essence there is no one-size-fits-all. From possibility perspective - as a general rule everything you can do in the inspector can be done from script, but not everything you can do from a script can be done from inspector.

Changing class structure, f.e. renaming or removing a field or property, is always a breaking change - the name says it all. Things will/may break. Same happens when you change the interface, that is change the name or remove methods (especially public methods, but also protected). This is why the Obsolete attribute exists, btw.

If you change your field "name" to "type" (sidenote - that's a really bad name, you should avoid names that exist as "special" names or keywords, even if the compiler let's you do that), what the inspector does is after your scripts compile, it will try to set the same values/references as they were before. The only key it has is the field name - so if you change it, it won't set it. It will not try to guess anything, as that could lead to unexpected behaviours and that's the worst.

So in short:
Once you have a class that's used, you either only do additions, or accept consequences (= fix) things that will break.
This is what the O in SOLID stands for and is, just IMHO, the most important rule of those 5, as it's the only one that if not kept can literally break your whole application.

 

I am not an English developer so "into or through/from " does not create a hard problem to understand a question!
Thank you but you didn't answer my question! my answer was not "don't use "type" variable name!!!"
I said if you initialize fields of a class within a script and change names of them ,their values will not be cleaned.
but if you use the inspector, all data values will be cleaned (in my example all names values of unit class array)

 

I actually think I did answer that:

(emphasis added)
+ some other info on why it works like that and that it's not something unusual.

You are exactly right in what Inspector will do (clear the values), because that is how it works. Since Inspector doesn't know your intent, if the field it has value for can't be found by it's name anymore ( = it doesn't exist) -> the value of it is assumed to not being needed either.
If you're familiar with databases, consider it storing the data temporary while the scripts compile and then doing an Insert, just without reporting errors that the column doesn't exist, and deleting the temporary data.
It has to work that way, otherwise it would need to keep all data entered in the Inspector forever.

If you want a stable, persistent data store that is resistant to changes, Inspector is not the way to go.
[removed scriptable objects from here], or a database of your choice or text files or anything else you want.

Just keep in mind what I wrote earlier - as long as you have saved persistent data somewhere, when you change the structure, things may break.
[removed scriptable objects from here]
Same as you won't lose the data on renaming a column in a database table, but your queries will stop working.
Text files will still have the data, but deserialization will fail/be incomplete.

That is just how it works and that is why I linked the SOLID principles. Unity works with Object Oriented Programming so in order to understand Unity, you need to understand OOP.

If you felt offended by the vocabulary clearing paragraph in the beginning, that wasn't my intention and I'm sorry for that.

The reason I even brought it up is because these words are not equivalent. If you would draw a data flow diagram of where the data is (and this is the core of your question - why your data dissappeared), it would look completely different just based on these words alone. That, and that alone, was the reason I corrected your sentences.

EDIT:
Checked the ScriptableObjects - they will also get cleared on structural changes, so I removed them from relevant parts. They are good in certain conditions, but this is not one of them, or at least wouldn't answer the original need.