none
Help to make it more fashionable in syntax RRS feed

  • Question

  • Hello Fellas,

    Need your help.

        class Boy
        {
            public Boy(string _Name, int _Multiply, int _Amount)
            {
                Name = _Name; Multiply = _Multiply; Amount = _Amount;
            }
            public string Name;
            public int Multiply;
            public int Amount;
        }

    Want to make such constructrions more laconic and fashionable.. maybe using some perls of Lambda expressions..
    Just tired of such stupid copiyng of the parameters.. I know there are some genius of Lambda among you, will appeciate all of your variants.


    "I = I + 1" .. Isn't it boolshit?

    Friday, October 4, 2019 4:40 AM

Answers

  • Why? If it works then don't change it. However you do have some design issues with your code. Firstly you should never expose fields publicly if they are writable. This dramatically limits what you can do and prevents you from making changes later.

    class Boy
    {
       public Boy ( string name, int multiply, int amount )
       {
          Name = name;
          Multiply = multiply;
          Amount = amount;
       }
    
       public string Name { get; set; }
       public int Multiply { get; set; }
       public int Amount { get; set; }
    }

    Secondly, unlike C++ and some other languages, if your constructors are doing nothing but setting properties that are writable to the public then you don't need the constructor. Just use the properties directly. Given C#'s object initializer syntax makes this pretty clean and far more flexible as you add more properites.

    class Boy
    {
       public string Name { get; set; }
       public int Multiply { get; set; }
       public int Amount { get; set; }
    }
    
    //Create an instance the long way
    var boy = new Boy();
    boy.Name = "Bob";
    boy.Multiply = 1;
    boy.Amount = 100;
    
    //Use object initializer
    var boy2 = new Boy() {
       Name = "Bob",
       Multiply = 1,
       Amount = 100
    };

    The only time you'd need a constructor is if you have complex initialization or you are setting properties that are readonly to callers.

    Next I'd recommend that you set some default values on your properties and outside of DTOs string properties should never return null. It just complicates things for the caller.

    class Boy
    {
       public string Name
       {
          get => _name ?? "";
          set => _name = value;     
       }
    
       public int Multiply { get; set; } = 1;
       public int Amount { get; set; }
    
       private string _name;
    }
    Notice the casing as well. In .NET public members and types are Pascal cased (member kind doesn't matter), parameters and locals are camel cased, fields are camel cased with a leading underscore.


    Michael Taylor http://www.michaeltaylorp3.net

    Friday, October 4, 2019 2:52 PM
    Moderator

All replies

  • Perhaps using this syntax.

    class Boy
    {
        public string Name { get; set; }
        public int Multiply { get; set; }
        public int Amount { get; set; }
        public override string ToString()
        {
            return Name;
        }
    }

    Create an instance

    var boy = new Boy() {Name = "Joe", Amount = 9, Multiply = 3};


    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Friday, October 4, 2019 10:36 AM
    Moderator
  • If you are using C# v7.1, you can shorten the code using a tuple:

    public Boy(string _Name, int _Multiply, int _Amount) => (Name, Multiply , Amount) = (_Name, _Multiply, _Amount);
    

    In version 7.1, the compiler optimizes away the construction and deconstruction of the tuple, so this will be efficient.
    Friday, October 4, 2019 12:53 PM
    Moderator
  • Why? If it works then don't change it. However you do have some design issues with your code. Firstly you should never expose fields publicly if they are writable. This dramatically limits what you can do and prevents you from making changes later.

    class Boy
    {
       public Boy ( string name, int multiply, int amount )
       {
          Name = name;
          Multiply = multiply;
          Amount = amount;
       }
    
       public string Name { get; set; }
       public int Multiply { get; set; }
       public int Amount { get; set; }
    }

    Secondly, unlike C++ and some other languages, if your constructors are doing nothing but setting properties that are writable to the public then you don't need the constructor. Just use the properties directly. Given C#'s object initializer syntax makes this pretty clean and far more flexible as you add more properites.

    class Boy
    {
       public string Name { get; set; }
       public int Multiply { get; set; }
       public int Amount { get; set; }
    }
    
    //Create an instance the long way
    var boy = new Boy();
    boy.Name = "Bob";
    boy.Multiply = 1;
    boy.Amount = 100;
    
    //Use object initializer
    var boy2 = new Boy() {
       Name = "Bob",
       Multiply = 1,
       Amount = 100
    };

    The only time you'd need a constructor is if you have complex initialization or you are setting properties that are readonly to callers.

    Next I'd recommend that you set some default values on your properties and outside of DTOs string properties should never return null. It just complicates things for the caller.

    class Boy
    {
       public string Name
       {
          get => _name ?? "";
          set => _name = value;     
       }
    
       public int Multiply { get; set; } = 1;
       public int Amount { get; set; }
    
       private string _name;
    }
    Notice the casing as well. In .NET public members and types are Pascal cased (member kind doesn't matter), parameters and locals are camel cased, fields are camel cased with a leading underscore.


    Michael Taylor http://www.michaeltaylorp3.net

    Friday, October 4, 2019 2:52 PM
    Moderator