: this() As a constructor

Question

I'm trying to get a better understanding of general practice... specifically deriving this() in a constructor. I understand that its less code, but I consider it less readable. Is it common/good practice to do it this way? Or is it better to write a second constructor that handles it specifically?

public SomeOtherStuff(string rabble) : this(rabble, "bloop") { }

or

Public SomeOtherStuff(string rabble)
{
    //set bloop
}

Any input would be greatly appreciated

Molten

this() is a good way to have auto-properties on a struct type and still allow them to be set in a parametrized constructor. Without the this(), it requires you to use explicit backing fields. – Strepitous

@Dan: That’s brilliant, I never thought of that! In future I’ll use this() in structs that have auto-properties! Thanks! – Garibaldi

Answer 1

It is good practice to use this() whenever possible. Otherwise you will be duplicating some code, which violates the DRY (Don’t Repeat Yourself) principle. The problem with repeating yourself is that every time you need to make a change — even if it’s a simple change to a single line of code — you have to remember to make the same change in multiple places, and keep the multiple copies synchronised.

You should only “duplicate” the code when you need to because it needs to be different, so it’s no longer a duplicate. This way, having a duplicate is a message to the reader that the code is actually different, and is so for a reason.

Garibaldi

Great answer and that definitely clarifies my question. I hadn't seen the DRY principle and I believe that will improve my code across the board. Thanks! – Molten

Answer 2

The problem with the two separate constructors is, that they often contain identical code, which may lead to problems with later refactorings, when one constructor is changed and the other not. So you could see constructor chaining with this() as an application of the DRY principle.

Qulllon

Answer 3

Initialization lists are very common practice in industry.

As for readability... that is a matter of opinion. But maintainability is usually a higher goal to strive for.

DRY is a good thing :)

Jamieson

Answer 4

That is how you chain constructors and it is a perfectly valid thing to do.

Unesco

Answer 5

I really like the first way (constructor chaining) but if you feel the second way is more readable then go for that and you could put whatever duplicate code you have in the constructors into a private method to avoid breaking the DRY principle people have mentioned.

Also, I also always try to code in the style of the code I'm working on - so if the predominant style is one or the other, I'd go with that style for consistency.

Ordinary

Answer 6

I care less about readability and more for reliability.

Chaining constructors is much better than copypasting constructor method bodies.

Sublease

I agree chaining constructors is better than copying code. Readability, however is very important. In this instance I think chaining constructors is more readable and much more reliable. But as a general statement, "not caring" about readability is a dangerous practice IMO. – Baseler

@foo Buggy and readable or obscure but reliable? Of course, its not always an either/or situation, but if you have the choice to do one or the other, better the other. Also, the most unreadable code becomes more than comprehensible with the application of code comments! – Sublease

Uh, why do you associate "buggy" with "readable"? How about "readable and reliable"? They are not mutually exclusive. – Unesco

@Will So are we talking sacrifice readability for speed? Or when given the choice between readability and reliability to pick reliability and back with clarifying comments? – Molten

@Ed never claimed such, in fact the comment directly above yours says it is "not always an either/or situation". @Brandon who said anything about speed? Did I mention speed? Let me ctrl-f... nope, nothing about speed. Reliability > readability, because readability can always be augmented with comments. Reliability does not care about code comments. Clear, everybody? – Sublease

@Will - It's weird how many people read your answer and thought you were advocating unreadable code, or suggesting readability should be sacrificed for "speed." I would expect programmers to be less prone than the general public to those types of inferences, just because computers don't let you get away with that kind of thing. ("Do what I want, not what I tell you!") – Cordell

Answer 7

another way to DRY is writing an initialization method, for example Init(rabble, bloop) and all constructors calls this method.

This tends to be less confusing and more flexible especially where there are many constructors.

Herd