Why does my short code have so many errors?

BrunoB

Well-known member
Joined
Nov 19, 2022
Messages
96
Programming Experience
Beginner
Hello good morning, here is my brief code, thank you.
C#:
amespace Example1
{
class Program
{
static void Main(string[] args)
{
private int age;
private float salary;
private string name;


Person p1 = new Person();
p1.setAge(20);

Console.WriteLine("the person's age is" + p1.getAge());
Console.ReadKey();

Bottle b1 = new Bottle();
b1.Capacity = 200;

Console.WriteLine("the bottle has a capacity " + b1.Capacity());
Console.ReadKey();
 
The field is private. The whole point is that you're supposed to use the property from the outside and the field is only accessible internally. You shouldn't even have declared that field and just used an auto-property.
 
Ok, everyone be cool. There are some fairly basic things wrong with the code but it's the start of a learning journey.

Bruno, you can't just fix errors by doing what the compiler tells you. It might say "expecting ;" but it doesn't necessarily mean that the correctly functioning code will have a ; where the compiler was expecting it..

I fixed the code to have no syntax errors but it's almost certainly incorrect from a logical point of view. It's similar to saying "cut a slice of sky and cook it using the toilet" - it's a syntactically correct sequence of English words but it's complete and utter nonsense
 
The field is private. The whole point is that you're supposed to use the property from the outside and the field is only accessible internally. You shouldn't even have declared that field and just used an auto-property.
but the auto properties does not support the introduction of if statements, etc., as I understand
 
but the auto properties does not support the introduction of if statements, etc., as I understand
That's correct. There are no if statements in the code you posted, so an auto-property would be appropriate in that case. If that's not your full code then you can ignore that advice. One of the reasons to use properties is that you can change the implementation without changing the interface, so you can switch between an auto-property and a full property without affecting any code that uses it.
 
That's correct. There are no if statements in the code you posted, so an auto-property would be appropriate in that case. If that's not your full code then you can ignore that advice. One of the reasons to use properties is that you can change the implementation without changing the interface, so you can switch between an auto-property and a full property without affecting any code that uses it.
excuse my ignorance what does implementation mean?
 
in coding terms, "how something is done"

If someone files a patent for a water boiling device that uses a heated element and a thermostat to prevent too much boiling then it's an idea, a concept. It's not something I can boil water in. The kettle I hold in my hand is the implementation of that idea - it has a particular shape, capacity, it has an on-off switch in a certain place, and a socket into which the electricity cord connects. This other kettle I have in my other hand also does all those same things, but it looks nothing like the first one; it is bigger, rounder, flatter, it has no cord because the cord is in the base on which the kettle sits, I twist the switch instead of pushing it down. It has a filter, but the other kettle does not, and it has a microcomputer that measures the water temperature 100 times a second and turns off at just the right time, rather than two metal rods glued together that bend in the heat and flick the switch off

I can, however, still use both kettles to boil water without any special training or a need to treat them significantly differently; they have the same interface - put water in, turn on, they turn off by themselves when they are done

Different implementations, same idea

In C# whether you have a class like this:

C#:
  public class Person{
    public int Age {get; set;}
  }

Or like this:
C#:
  public class Person{
    string a;
    public int Age{ 
      get => int.Parse(n);
      set => n = value.ToString(); 
    }
  }

You still use it like this:

C#:
  var p = new Person();
  p.Age= 20;

They might work slightly differently inside (one stores the age as a string, the other stores it as an int), but to other classes outside them that use them, they look the same. They have the same interface, but a different implementation
 
Back
Top Bottom