C# code survey
-
Good to know that named parameters were actually implemented. At my job, we're still using VS 2008, so I wasn't aware that they had taken my advice!
:) You should really try and get them to update or you should go somewhere else. That sound ridiculous to still be using VS2008.
-
:) You should really try and get them to update or you should go somewhere else. That sound ridiculous to still be using VS2008.
-
Could you not just use inheritance and do away with all the property setting?
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass : FooDto
{
// ....
}This exposes properties T1 ... T24 of the base FooDto class but that may or may not be an issue. There are arguments against combining DTOs and inheritance, so without knowing the details of your implementation this may not be appropriate. Part of "knowing the details" of course involves the use of a crystal ball to envisage future changes, but depending on the scenario you can pretty much rule out a lot of potential stuff and, in this case, save yourself a lot of code.
Such a FoodDto is absolutely useless, a snapshot in time... There is little point in deriving from it... This FooDto sole purpose is to be turned into json and vice versa. It comes from an object that do update each individual property in real time (mostly hardware read status)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Yes it's a programming question, but wait a moment, I am NOT asking to solve any problem here, I am asking to select your favourite of 2 options. I think what they want me to do here at work is disgusting. I have to suck it up anyway, since it's the guy who accepts pull request that tells me to do it, period. But I am curious whether or not I am in good company with my prejudice. It's about DTO, constructors with zillion of parameters and all private properties. code I prefer and put in my pull request, with 24 properties (i.e large number of properties)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I believe there are reasons for either style and I don't mean a simple preference by the developer. The first style allows you to initialise an object with some default values and gradually fill its properties with desired non-default values. Also it allows you to change those values over time to reflect changes in how the class (or another dependent class) should behave. You can see that in any visual component for UWP/WPF/ASP.NET. Meanwhile, the second style creates a kind of immutable object (it can only be read although its properties can still be changed due to internal operations, if any). Changes to this data may not be desired due to e.g. the intended design of the application (or API) or legal reasons. If you must follow the second style with a class with so many constructor arguments (with which I agree it might be a code smell), I'd recommend creating a Builder for the object. MyFooClass in this example seems to be one which might actually hint at why the guy wanted you to change the code style; perhaps he thought you were trying to create in MyFooClass a Builder for FooDto and wanted you to make it so both classes don't repeat themselves. Anyway, I'd recommend approaching the guy with an open mind to try and understand his motivations for requesting the style change; it may either enhance your knowledge of the application or the guy you're working with. [UPDATED] Both Dan's or Marc's answers offer a great alternative to avoiding so many arguments on the constructor. I'd also check if you could go either way.
- Leonardo
-
Yes it's a programming question, but wait a moment, I am NOT asking to solve any problem here, I am asking to select your favourite of 2 options. I think what they want me to do here at work is disgusting. I have to suck it up anyway, since it's the guy who accepts pull request that tells me to do it, period. But I am curious whether or not I am in good company with my prejudice. It's about DTO, constructors with zillion of parameters and all private properties. code I prefer and put in my pull request, with 24 properties (i.e large number of properties)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Such a FoodDto is absolutely useless, a snapshot in time... There is little point in deriving from it... This FooDto sole purpose is to be turned into json and vice versa. It comes from an object that do update each individual property in real time (mostly hardware read status)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
would be nice... unfortunately the way the DLL dependency tree is set... can't happen... i.e. the FooClass is in a DLL that reference the assembly where FooDto is defined.... FooDto is in a common contract assembly...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I personally don't like either option. Why create two classes that duplicate the same information. I would create a property in MyFooClass to point to FooDto. Or better yet, inherent MyFooClass from FooDto.
FooDto could be final for all we care. its whole intent, purpose, life cycle, is to turn Data into JSON and vice versa. Nothing more.... mm.. I'd like the idea of justsharing my own internal status class... but that won't fly either.. plus I have been forced to take in some dependency that prevent having these internal status in shared library.. So I do need to duplicate them in contract library upon which I depend
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Yes it's a programming question, but wait a moment, I am NOT asking to solve any problem here, I am asking to select your favourite of 2 options. I think what they want me to do here at work is disgusting. I have to suck it up anyway, since it's the guy who accepts pull request that tells me to do it, period. But I am curious whether or not I am in good company with my prejudice. It's about DTO, constructors with zillion of parameters and all private properties. code I prefer and put in my pull request, with 24 properties (i.e large number of properties)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
To quote Alan Perlis: If you create a function with 10 arguments, you probably missed one.
-
Yes it's a programming question, but wait a moment, I am NOT asking to solve any problem here, I am asking to select your favourite of 2 options. I think what they want me to do here at work is disgusting. I have to suck it up anyway, since it's the guy who accepts pull request that tells me to do it, period. But I am curious whether or not I am in good company with my prejudice. It's about DTO, constructors with zillion of parameters and all private properties. code I prefer and put in my pull request, with 24 properties (i.e large number of properties)
public class FooDto
{
public T1 Property1 { get; set; }
// ....
public T24 Property24 { get; set; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto() { Property1 = property1, //.... Property24 = property24, }; }}
how I have asked to rewrite the code, feels disgusting to me, but curious how many people share, or dislike, my opinion
public class FooDto
{
public FooDto(T1 value1 /** 24 values later */, T24 value24)
{
Property1 = value1;
// .....
Property24 = value24;
}public T1 Property1 { get; }
// ....
public T24 Property24 { get; }
}
// ....
class MyFooClass
{
private T1 property1;
// ....
private T24 property24;public FooDto ToDto() { return new FooDto(property1 /\*\* \*/, property24); }}
In his defence he has an argument. If someone use that DTO as well, the compiler will force them to initialise all values. Though one could counter argument that we got unit test for just that. At any rate, which of those 2 is your favourite code style?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Option 2. There should never be a possibility where an object can get constructed without it being initialized properly. Making them mandatory or optional parameters to a constructor achieves that, and the compiler will find every last place where someone has initialized the object incorrectly. Not only that, it'll run very early in the development process, ensuring that the developer that just added the new parameter has all those details still fresh in their head when the bugs are found. What better unit test could you possibly hope for? The other aspect of how you've been asked to rewrite that code is also a better practice -- you've been asked to reduce the public interface by removing the property setters. This just ensures that nobody can reach into your object and twiddle those properties after it's been constructed. If someone needs that, they can change your code, but hopefully they will evaluate whether there's a better that ensures the object can't be put in a bad state. If the object can't ever be put in a bad state, you can't have bugs because someone was sloppy.
I live in Oregon, and I'm an engineer.