Nimit Johri
Nimit Johri

Reputation: 23

Is it better to declare all methods to be called from main() as static or create an object of the class containing all the methods including main?

I need to know in general which is the preferred way in scenarios like below:

I have the main function in a class "Program" along with a few other functions. I have broken down my logic into functions and calling it all from my main.

Now to call the functions from my main, i have two options:

1 - Make all the methods static

2 - Create an object of class "Program" in main() and call object.Method()

I want to learn the preferred way for all my future coding endeavors

I have something like


class Program
{
    public static void main()
    {
        CheckFile();
        ReadFiles();
        PushToDB(); 
    }

    private bool CheckFile() {...}

    private string[] ReadFiles() {...}

    private string PushToDB() {...}
}

Upvotes: 1

Views: 907

Answers (2)

Theodor Zoulias
Theodor Zoulias

Reputation: 43748

If you are writing a utility program with straight forward logic (do A, then B, then C, then close), the kind of program that is no more than 200 lines of code and can be implemented in one day, and rarely revisited after that, then I think it's OK keeping the methods static.

On the other hand if the program is bigger and more complex, then at some point it'll tell you itself that it needs a more subtle engineering. 😃

Upvotes: 1

Scott Hannen
Scott Hannen

Reputation: 29252

TL;DR It's better to put your code in its own classes, not directly in the console application, unless it's trivial.


To the extent that's practical, our code shouldn't know whether it's being executed in a console app, web app, etc.

So, while there's not some rule, here's a suggestion about where to put your code:

  • Best - create a separate class library and put your class there.
  • Second best - create a unit test application and put your class there. You can move it later.
  • Third best - create a separate class in your console application. You can move it later.
  • Distant fourth, not ideal: Put it directly in your Program class.

The reason why putting it in a separate class library helps is because it will help you avoid accidentally writing to the console output (Console.WriteLine) in your class, since your class doesn't know whether it's executing in a console app or somewhere else.

Regardless of where you put the classes, separate classes are better because it encourages you to break even small functionality into separate units. I'm not saying that we need to be all rigid about this, but it does make life easier.

For example, you might want to create one class that just does the ReadFiles part, and another for the PushToDb part. If you create a class like this:

public class FileReader
{
    public string[] ReadFile(string filePath)
    {
        // read some files and populate some data
    }
}

Then it's much easier to test just that one part of it. As we write all of this we're going to make tiny mistakes in both the part that reads the data and the part that saves it to the database. Instead of trying to work on both at once, this enables us to work on just one part at a time and test it before going to the next part.

The reason why I mention a unit test project is because it's also easier to test individual pieces of code in a unit test project than in a console application. If you want to test a piece of code in a console application you have to edit it to run this part, then edit again to run that part, and so on.

But if you write unit tests then you can run one test, run the other test, run the first test again, or run all the tests together. Unlike the console app you don't have to keep modifying the code to tell it which part to run.

And, although I haven't included any real explanation of unit tests in this answer, it's a really great habit to get into. I wish I had known about them for years and years when I was constantly writing console apps to test my code. Unit tests are an awesome habit that some developers like me learn late and some never learn. If you get into the habit early it will make your future coding much more fun and easy.

Upvotes: 3

Related Questions