Should I declare my abstract class's attributes with get; set;?

I'm making a little program that will crawl my hard drive and present a list of file found in a given drive.

My idea is to have a base File class, and implement Picture.cs, Video.cs and Document.cs classes inherited from the File.cs class.

Here's my code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SharpLibrary_MediaManager
{
    public abstract class File
    {
        public string name;
        public string fileType;
      开发者_运维知识库  public int size;
        public DateTime creationDate;
        public DateTime modificationDate;        
    }
}

Should I declare the short hand code for each attribute like this:

public string name { get; set; }

Any guidance will be helpful. Thank you. :)

Edit:

I mean literally replacing this line:

public string name;

with this line:

public string name { get; set; }

First, "attributes" is not the correct terminolgy here. When you declare a member of a class that has get and/or set defined (formally known as "accessors"), you are defining a property. Properties are a convenient way to expose values of private fields because you can add logic to the getting and setting mechanims.

Second, when you declare a member name as you've done via

public string name { get; set; } 

the compiler will expand that into the following:

private string _name;
public string name {
    get {
        return _name;
    }
    set {
        _name = value;
    }
}

That is, the compiler will automatically create a backing field for you and define the accessors. These are called "automatic properties" (for the people)¹.

Third, you should never² publically expose fields. So, if you want to expose the string name as part of your public interface it is better to do it as a property. First, it provides better encapsulation. Second, it can be declared virtual and overridden in dervied classes. Third, you can have custom logic. Fourth, you can have different levels of accessibly between the reading and writing mechanisms on properties but you can not on a field.

Fourth, per accepted naming convetions, public properties should be named with CamelCase so that you should prefer Name instead of name.

¹: Sorry, bad joke that I've been waiting a long time to make.

²: Almost never.

You're not describing a short hand syntax for a single item but rather 2 completely different types of members. The get/set version creates a C# Property while the non-get/set version creates a field.

// field
public string name;  

// property
public string name {get; set;}

So what you're actually asking here is whether or not you should expose name as a field or a property. The answer is almost certainly property.

If your looking to have these properties, which is what adding the { get; set; } will make the variables, then you should declare the set; part of the property as protected.

So it becomes:

public string name { get; protected set; }

The advantage of this is that you are guaranteeing that the property can only be set by either the base class, or any class that inherits the base class.

As others have suggested, following the C# naming conventions is a good idea and also using properties are highly recommended.

Just to be clear, attributes are means to do declarative programming. They are used to decorate methods, classes, etc. msdn link

If you're asking whether to expose properties rather than public fields, then the answer is Yes.

You should also use PascalCase for the property names rather than camelCase:

public string Name { get; set; }
public string FileType { get; set; }
// etc

As Luke says, all things being equal, properties are preferred to fields.

In addition you may want to change the casing of your fields to match standard C# naming conventions.

Lastly, you might want to avoid the "File" name for your class as you'll probably be using the System.IO namespace which also has a File class. Also, System.IO.FileInfo may already include many of the properties you are planning on creating -- there's no point reinventing the wheel.

I believe another advantage of properties over normal public fields will be ability to override them in the derived class.

class Base
{
public virtual int X
{
get
{
Console.Write("Base GET");
return 10;
}
set
{
Console.Write("Base SET");
}
}
}

class Derived : Base
{
public override int X
{
get
{
Console.Write("Derived GET");
return 10;
}
set
{
Console.Write("Derived SET");
}
}
}

Another useful trick that is applicable while using properties is the ability to modify the modifier of the the derived Properties like changing from Public access to Protected.

Hence in many ways its better to use properties in base class to derive.