vtcoder

We're toying with the thought of adding a standard practice to our company's guidelines to always call the base constructor from any class, e.g.:

Code Snippet

class MyClass

{

public MyClass()

: base()

{

}

}

The reason behind this is that it makes the call stack of constructors very clear, and it makes the programmer more aware of this fact. We've found that the difference between constructor calls and non-constructor OOP principles (override, hide, seal, w/ polymorphism etc) are either confusing or overlooked by some (especially by new programmers). This call to the base constructor ensures that each class was developed with explicit knowledge of what is going on.

Along similar lines, we encourace always defining a default constructor and explicit access modifier to make it obvious that the coder intended everything explicitely.

I was just wondering if anyone else has considered this as a good coding practice, and why (if different than what I list) or why not. And also if there are any other explicit practices that I'm not listing that would be a good idea to include.

Thanks



Re: Architecture General Standard for base constructors

J. Ambrose Little

Hi vtcoder,

I can see the reasoning for what you're saying, but I wouldn't put it high on my list of standards just because if a dev doesn't understand that not declaring a constructor means you automatically get one, and not explicitly calling base means it'll call the default one (if there), you got more serious problems.

Personally, I'd say things like following MS naming conventions for public types and type members, using an enterprise framework (e.g., EntLib) for exception handling, logging, security, etc., using domain-driven design/good OOD (including the use of a good OOD framework), and using XML comments to document your code rank much higher in importance. It's not to say your point isn't valid, but if you're trying to get a bunch of individuals to conform to a set of guidelines, you need to focus in on what's really important, keeping the list rememberably short. Also, if you're using code generation of some kind, it's easy enough to setup the explicit default constructor. Not so easy to ensure the other things listed above using templates.

When designing standards and conventions, it's easy to lose sight of what's important and end up with an unmanageable and unusable list of things that not even the most conscientious dev will remember or be able to fully adhere to. Or maybe, if you do want to list every little thing, at least have a "this is really important" list and "these are suggested/recommendations" list. The things that go in the first are must haves (things you'd build check-in policies around for TFS and focus on in code/design reviews) and things that go in the second are more like reading code complete; they're like to haves that you'd encourage your devs to read.






Re: Architecture General Standard for base constructors

Martin Platt

First of all, I'd say read Code Complete, I read the first one, not got to the second edition, but I'd imagine you'd get similar concepts.

I think that there's a danger of making something standard practice, only to provide training for those that don't fully understand how to program. Instead I'd be concentrating on naming, commenting, unit testing, defensive programming, nicely partitioned well designed software, design patterns, TDD, things like that. For the new people, perhaps try pair programming, or at least give them a really good mentor who watches for things like that for them. Either that or buy the company some books for certs and get the new people to study them and take the exam Benefits both parties then.

I guess from the point of view of clarify, it probably wouldn't hurt to do it, but possibly that fact might hide what happens from those new programmers who have never seen the default constructor called for you, or that there is always a default constructor whether you supply one or not.

I hope that helps you out a little.

Martin.




Re: Architecture General Standard for base constructors

Ollie Riches

Jsut adding to what was said above, do you have a copy of the 'Framework Design Guidelines' by Cwalina & Abrams.

I have just checked my copy and it doesn't mention anything around the explicit calling of base constructors.

I don't know if you use them but have you had a look at the Philips coding standards produced for C#, therse are publicly available and provide a good source of standards IMO.

http://www.tiobe.com/standards/gemrcsharpcs.pdf

HTH

Ollie Riches






Re: Architecture General Standard for base constructors

vtcoder

I've seen this guideline. It is pretty thorough.

Thanks for all of your comments. I agree that this is certainly not the most urgent standard to be worried about, but I like it because it makes you carefully consider your base constructor, and I really don't like default anything.





Re: Architecture General Standard for base constructors

Martin Platt

I definitely haven't seen that done before, as a standard at least, only when required.

My view on this is more that you should carefully consider all code that you write, regardless of what standards you have in place. A good way to enforce this on everything would be to do test driven development. You have to consider the test that you need to make to ensure that a particular aspect of the system is working, then code to that test. In that way, regardless of implementation, you are more likely to have fully considered scenarios, and pre-existing tests will warn you of anything that you forgot about too!

I hope that helps you a little,

Martin.






Re: Architecture General Standard for base constructors

Diego Dagum

Something else I'd like to say about having as a standard OOP practice creating always a base constructor is the fact that such principle clashes with the immutability principle

Immutability is a faculty you may assign to some properties in order to give them the chance to be setted just when constructing the instance (as constructor arguments) but later those properties can be changed just by the instance itself (i.e. by direct assignment to the private field a property like that is based on)

Therefore, those properties can just have getter method but not setter

Immutable properties are cool to avoid dirty practices which violate encapsulation. For instance, imagine you are coding a connection pool (my example is outdated bcs nowadays these pools come with the managed platforms like Java EE or .NET, but for the sake of the example it works)

Imagine your pool need to have two specific properties: MaximumConnections and MinimumConnections. The first one indicates that attempting to ask the pool for an extra concurrent connection once that maximum was reached will derivate in an exception. The MinimumConnections property indicates how many connections must be available any time, even if no one is borrowing connections to the pool

But you need something extra: you need those properties frozen. Everybody can get those from the pool, but no one can set them. In that case, it's said those properties are immutable and in .NET you code immutable properties by writing the get() method on them but not the set() method

So... if they don't have setter... how to assign the initial value Usually properties reside on private fields, so you should code the Pool constructor receiving a couple of arguments: max and min. Thus, you assign those arguments to the underlaying fields for MaximumConnections and MinimumConnections and that way you can be sure that no one else will touch their values

Eventually you'll need a third immutable property for the Pool: BorrowedConnections. This property tells how many connectors are actually assigned (in use), and therefore unavailable. Despite in this case you don't need to have this immutable property as an argument for the constructor, you still need that the owner instance is the only updater of it. But this goes beyond

So, regarding your question about whether it is or not a good practice having base constructors, in case you need to implement immutable properties like those on the examples above, the base constructor will oblige you to create specific getters for those properties and, that way, the immutability evanishes






Re: Architecture General Standard for base constructors

vtcoder

Thanks again for all the input. I agree that requiring base constructor calls as a standard rides the fence in terms usefulness. I see the point that if your devs don't understand constructors in OOP the standard won't help. But, I hope that it would make newer devs become aware of (and dig into) this sooner as they see it in the code and have to think through it. Just a thought. I just tend to like explicit standards where possible.

To respond to the issue of immutability, I may be missing some of your point, but I think that a standard to explicitely list base constructor calls would not interfere with setting up an immutable class, or read-only properties. In the case of an immutable class, and/or a class with read-only properties, it will still make a call to its base constructor regardless. So my point is why not make this explicit so there is less confusion (since constructors in OOP are a little different than other methods).

For example, here is a class like you mention with explicit base constructor calls:

Code Snippet

public class MyClass : MyBaseClass

{

private string _myProperty;

public MyClass(string myProperty)

: base()

{

_myProperty = myProperty;

}

public MyClass(string myProperty, string myBaseProperty)

: base(myBaseProperty)

{

_myProperty = myProperty;

}

public string MyProperty

{

get { return _myProperty; }

}

}

This makes following the actual constructor chain very obvious from glancing at the code and it doesn't interfere with the read-only property. If I'm missing something in your argument just let me know.

Thanks