The problem of your code is not in the differences you've demonstrated, but in other parts.
First of all, your field declarations are redundant. You should better use auto-implemented properties (as far as I remember, with C# v.3 or later):
public partial class Weeds {
public string Name { get; set; }
}
Also, if this class or these properties are only used inside the same assembly, consider using
internal instead of
public. Same goes about your constructors. Besides, if you initialize the backing fields in a constructor (your second option, which is perfectly fine), consider keeping setter private, as the constructor might be the only place where you would allow to modify the fields:
public partial class Weeds {
public void Chicory(string name, string edible, string feed) {
this.Name = name;
}
public string Name { get; private set; }
}
So, the choice between having the fields initialized in constructor and letting the properties read/write is defined by semantic of your code, design of it from the convenience point of view and other design consideration. There is not a one clear-cut decision; either way could be fine.
And, finally, the <bbiggest> problem of your code is the use of hard-coded
immediate constants like "Chicory". I cannot see situations when it can be potentially used, except some preliminary version existing only during development and first tests. You should use something else, depending on your goals. In particular, it could be enumerations, possibly with resources (please see my article
Human-readable Enumeration Meta-data[
^], for a clear example), but it could be something else. Hard-coding as you demonstrated it is simply not acceptable.
—SA