Does main is a pain also apply to c#

WB1975

Well-known member
Joined
Apr 3, 2020
Messages
87
Programming Experience
Beginner
I have a little bit of a java background

Does main is a pain also apply to c#

how do you launch your console applications? what is standard practice?
 
I'm not 100% sure what you mean. Are you talking about how to execute your app, or how to write the Main method itself? If you create a Console Application project then a Program class with a Main method that will be the entry point for the app. Does that cover it?
 
I'm not 100% sure what you mean. Are you talking about how to execute your app, or how to write the Main method itself? If you create a Console Application project then a Program class with a Main method that will be the entry point for the app. Does that cover it?

ok so its just pretty straight forward, there is no elaborate way of setting up a program to start


this article explains how a java program should be started, I was just wondering if c# saw things the same way.
 
Dumping all the code inside the entry point is common to all programming languages when a beginner is still learning. I've seen it in Pascal, C, C++, VB, C#, VB.NET, LISP, Smalltalk, assembly, Forth, etc. It's a matter of how the student programmer eventually discovers the power and beauty of using subroutines and modules.
 
That's nothing to do with the language. Main is the entry point and, if the developer doesn't know any better, they'll just write all their code in that method. They start with small programs that it wouldn't be worth doing any other way and slowly move to bigger and bigger programs with more and more code. If no one ever tells them how to structure it, they won't spontaneously move it elsewhere until they realise that it's getting too big to manage and then they ask how to do it differently. If you don't want to put all your code in the Main method then don't. No language is going to make you do so or stop you doing so.
 
I'm rusty with Java, but my understanding is that .JAR files let you have multiple classes with each class potentially declaring it's own main(), although most of the Java specific IDE's try to stop you from doing this. Without an IDE and doing everything command line, this works without issues:
C#:
PS E:\z\test> cat A.java
public class A {
    public static void main(String[] args){
        System.out.println("A");
    }
}
PS E:\z\test> cat B.java
public class B {
    public static void main(String[] args){
        System.out.println("B");
    }
}
PS E:\z\test> javac A.java
PS E:\z\test> javac B.java
PS E:\z\test> jar cvf test.jar A.class B.class
added manifest
adding: A.class(in = 393) (out= 271)(deflated 31%)
adding: B.class(in = 393) (out= 271)(deflated 31%)
PS E:\z\test>

This is different in the .NET Framework: each assembly can only have at most one Main(). (I've heard there is a way to override this, but one has to bend over backwards to do this.)

I suspect that this is another raison d'etre for that article. He wants Java beginners to work within the confines of their IDE and have only one project and within that project only one entry point while doing the exercises. Obviously, that doesn't scale well when you need to keep throwing away the code in main(). It also prevents the student from looking back at previous exercises if they have thrown it away.
 
I also have another suspicion about why the author was pushing for a single entry point. Other than the fact that it is easier to find just one instead of multiple, there is also the issue of Java's (insane?) need to impose a strict directory structure and naming convention. If the class name does not match the filename, the compiler bitches at you. Of the namespace does not match the directory hierarchy, the compiler bitches at you. So given that, if you have multiple entry points, you would have to search multiple directories to find it.

Slightly off topic: Yes, I know that some Java to C# converts are trying to make traditional C# programmers to also follow the Java convention of making the directory structure match the namespace hierarchy. I think there maybe even a StyleCop rule for it. I don't get why impose this rule?
 
This is different in the .NET Framework: each assembly can only have at most one Main(). (I've heard there is a way to override this, but one has to bend over backwards to do this.)
I just tested this and you're correct, except for the "bend over backwards" bit. I just created a C# WinForms app and then created a copy of the Program.cs file, which contains the Program class, which contains the Main method. I changed the name of the copied file to Program2.cs and the class to Program2. I tried to build and it did indeed complain that I had multiple Main methods. I then went to the Application page of the project properties, where the Startup object field was (Not set). I selected one of the types containing a Main method from the drop-down and was then able to build successfully. According to the error message, that field sets the "/main" compilation option to specify the entry point.
 
That's what I get for playing with early beta versions of the language and not keeping up with changes. It used to be hard. :)
 
So none of this is really an issue for a beginner then is it?

i have just done this for my little program

i have a class called MainMethod which contains only the main method.

C#:
using System;

namespace FootballLeague
{
    class MainMethod
    {
        static void Main(string[] args)
        {
            Program myProgram = new Program();
           
            myProgram.MainProgram();
        }
    }
}

in the main method i instantiate an instance of Program

and run the programs logic in the MainProgram method.

C#:
using System;
using System.Collections.Generic;
using System.Text;

namespace FootballLeague
{
    class Program
    {
        public void MainProgram()
        {
            Questionaire userQuestions = new Questionaire();

            userQuestions.WelcomeUser();
            userQuestions.UserQuestionaire();
        }
       
    }
}
 
Seems pointless to me. Unless the intent is that in the near future you will also be running unit tests against your MainProgram class, or that you are trying to avoid static methods, then the extra indirection only serves to confuse things.

I will admit that I do something similar as the above, but I DO use unit tests, and I avoid using static methods within classes (even when Visual Studio and/or ReSharper are warning me that a method can be marked as static).

For the above, I would have simply re-written it as:
C#:
using System;
using System.Collections.Generic;
using System.Text;

namespace FootballLeague
{
    class Program
    {
        public void MainProgram()
        {
            Questionaire userQuestions = new Questionaire();

            userQuestions.WelcomeUser();
            userQuestions.UserQuestionaire();
        }
       
        static void Main(string[] args) => (new Program()).MainProgram();
    }
}
 
" I avoid using static methods within classes " are you talking about my ConsoleManager class or the main static method or all?
 
Neither. I was referring to the common beginner practice of going from:
C#:
public static void Main()
{
    // lots and lots of code here composed of:
    //    first modular part
    //    second modular part
    //    third modular part
    //    :
    //    n-th modular part
}

to

C#:
public static void Main()
{
    FirstModularPart();
    SecondModularPart();
    ThirdModularPart();
    :
    NthModularPart();
}

private static void FirstModularPart()
{
    // modular section of code here
}

private static void SecondModularPart()
{
    // modular section of code here
}

private static void ThirdModularPart()
{
    // modular section of code here
}

:

private static void NthModularPart()
{
    // modular section of code here
}

This is a good first step. The programmer is seeing obvious places to use subroutines. But I would rather see the code further refactored as:

C#:
public static void Main()
{
    (new Program()).Run();
}

void Run()
{
    FirstModularPart();
    SecondModularPart();
    ThirdModularPart();
    :
    NthModularPart();
}

void FirstModularPart()
{
    // modular section of code here
}

void SecondModularPart()
{
    // modular section of code here
}

void ThirdModularPart()
{
    // modular section of code here
}

:

void NthModularPart()
{
    // modular section of code here
}

(Yes, I don't write out private when it is implied. I know some users prefer to see it explicitly written, and Visual Studio's StyleCop suggests that it also be written.)
 
I avoid using static methods within classes

There are benefits of having static methods in non static classes but in rare cases. And in strict circumstances, If I am making a class for instantiation, I avoid putting static references/methods into it unless they are required for some odd reason...
 
Back
Top Bottom