By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,341 Members | 1,396 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,341 IT Pros & Developers. It's quick & easy.

A couple questions of style

P: n/a
I'm always curious on some of these style issues if there seem to actually
be objective reasons for doing things one way or the other, so here goes for
a little lighter discussion.

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?

2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region. Lately I've seen code where they are scattered in the
various regions where they are actually used - near the corresponding
property code, for example. The latter seems a bit more useful for someone
like me who loves regions.
Nov 15 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Hi Daniel,
1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?
I usually write a constructor myself (to be more exact, when you add a new
class from the IDE, the empty constructor is already written for you).
2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region.
This is the style I prefer. In my classes, I usually organize code like
this:

Constants
Private members
Constructor(s)
Public methods
Public properties
Public events
Protected methods
Protected properties
Protected events
Internal methods
Internal properties
Internal events
Private methods
Private properties
Private events

If there are some static members, they go before the instance ones in the
order outlined above.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... I'm always curious on some of these style issues if there seem to actually
be objective reasons for doing things one way or the other, so here goes for a little lighter discussion.

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?

2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region. Lately I've seen code where they are scattered in the various regions where they are actually used - near the corresponding
property code, for example. The latter seems a bit more useful for someone like me who loves regions.


Nov 15 '05 #2

P: n/a

Hi Daniel,

Thanks for posting in this group.
Personally, I think:
1). Because the compiler will generate a default constructor for you, there
is no matter whether you create a empty constructor or not.
2). I think if one class variable is only for property usage, I prefer to
create the variable just above the property definition. I will place other
non-static variables in the same region.

This is just a personally programming style, let's hear some others'
suggestion.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 15 '05 #3

P: n/a
Daniel.... I would lean to explicitly writing an empty constructor if I
wanted to support an empty constructor. If someone updates your code
and adds a custom construtor, the default constructor will be silently
removed!

I usually declare variables at the top. If the variable is _only_ used
in a
local section of code, then I would put it close to the code. This is
the
"principle of proximity," Code Complete, Mcconnell.

Regards,
Jeff
1) Default constructors. Do you always write a constructor for every

class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #4

P: n/a
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message news:<##**************@tk2msftngp13.phx.gbl>...
I'm always curious on some of these style issues if there seem to actually
be objective reasons for doing things one way or the other, so here goes for
a little lighter discussion.

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?
I like my code lean and mean, so I delete everything unnecessary. It
saves me the trouble of thinking "... ok, default constructor that
doesn't do anything..."

2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region. Lately I've seen code where they are scattered in the
various regions where they are actually used - near the corresponding
property code, for example. The latter seems a bit more useful for someone
like me who loves regions.


I would rather see the member declarations collected at the top, so I
can think "ok, this class has abc and provides services xyz".
Nov 15 '05 #5

P: n/a
Agreeing with Kevin, whats the point of a default constructor that does
nothing, yet leaves the object in an invalid state?

COM forced us to perform initialization through a myriad of Property setting
or via an uncommon "Initialize" or Init or whatever the component designer
decided on, which was always a "bad thing" since Components that rely on
particular states can become very hard to program and henceforth hard to
debug if the only way to achieve the proper state is through setting
multiple, possibly "un-grouped" properties before the Component is in a
valid state to do something...

I also get somewhat irritated with some of the .NET Framework functions,
specifically the WebServices where an object that is passed via parameter or
return value from the web service is REQUIRED to have a default constructor
and settable properties, instead of utilizing a Serialization [via
ISerializable] technique to remove this "defalt constructor" requirement.
--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
er**@cc.ensoft-software.com [remove the first "CC."]
"Kevin Cline" <kc******@hotmail.com> wrote in message
news:ba**************************@posting.google.c om...
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message

news:<##**************@tk2msftngp13.phx.gbl>...
I'm always curious on some of these style issues if there seem to actually be objective reasons for doing things one way or the other, so here goes for a little lighter discussion.

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?


I like my code lean and mean, so I delete everything unnecessary. It
saves me the trouble of thinking "... ok, default constructor that
doesn't do anything..."

2) Regions. I really really like the region feature for organizing code and reducing noise in the IDE. I've seen quite a bit of code where people put all the private class variables together right at the top of the class in their own region. Lately I've seen code where they are scattered in the various regions where they are actually used - near the corresponding
property code, for example. The latter seems a bit more useful for someone like me who loves regions.


I would rather see the member declarations collected at the top, so I
can think "ok, this class has abc and provides services xyz".

Nov 15 '05 #6

P: n/a
Eric Newton wrote:
Agreeing with Kevin, whats the point of a default constructor that
does nothing, yet leaves the object in an invalid state?


The assumption of course is that calling a parameterless constructor
yields an object whose state is not valid. Such should not be the case.

Personally, I prefer to code my own constructors simply to make the
design clear. Why force readers to wonder where a default constructor
originates in your object hierarchy when you can answer the question
with a single line of code?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
Nov 15 '05 #7

P: n/a
EventArgs constructors.

I normally block the parameterless default ctor in favour of enforcing event
parameter rules on the constructor rather than propertys (they are still
available) but i enforce minimum construction.

"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:uO**************@TK2MSFTNGP12.phx.gbl...
Eric Newton wrote:
Agreeing with Kevin, whats the point of a default constructor that
does nothing, yet leaves the object in an invalid state?


The assumption of course is that calling a parameterless constructor
yields an object whose state is not valid. Such should not be the case.

Personally, I prefer to code my own constructors simply to make the
design clear. Why force readers to wonder where a default constructor
originates in your object hierarchy when you can answer the question
with a single line of code?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

Nov 15 '05 #8

P: n/a
Indeed! This is one of those points that is both good and objective I was
talking about (as opposed to purely personal style) and hadn't considered.

"Jeff Louie" <je********@yahoo.com> wrote in message
news:e5**************@TK2MSFTNGP12.phx.gbl...
Daniel.... I would lean to explicitly writing an empty constructor if I
wanted to support an empty constructor. If someone updates your code
and adds a custom construtor, the default constructor will be silently
removed!

Nov 15 '05 #9

P: n/a
Indeed Frank. In fact, I think declaring the simple constructor also has
the side-effect of explicitly announcing that the object will be in a valid
state at that point, doesn't it? That seems like a good thing to me.

"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:uO**************@TK2MSFTNGP12.phx.gbl...
Eric Newton wrote:
Agreeing with Kevin, whats the point of a default constructor that
does nothing, yet leaves the object in an invalid state?


The assumption of course is that calling a parameterless constructor
yields an object whose state is not valid. Such should not be the case.

Nov 15 '05 #10

P: n/a
Frank Oquendo <fr****@acadxpin.com> wrote:
Why force readers to wonder where a default constructor
originates in your object hierarchy when you can answer the question
with a single line of code?


I'm not quite sure what you mean here. A constructor can *only*
originate in the class itself - it's not like constructors are
inherited.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #11

P: n/a
Jon, how would you describe the following behavior, in that
DEF._someInteger will = 20 , without saying DEF inherits the constructor?

class ABC
{
protected int _someInteger;
public ABC()
{
_someInteger = 20;
}
}

class DEF : ABC
{
}
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
Frank Oquendo <fr****@acadxpin.com> wrote:
Why force readers to wonder where a default constructor
originates in your object hierarchy when you can answer the question
with a single line of code?


I'm not quite sure what you mean here. A constructor can *only*
originate in the class itself - it's not like constructors are
inherited.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #12

P: n/a
Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:
Jon, how would you describe the following behavior, in that
DEF._someInteger will = 20 , without saying DEF inherits the constructor?


I would say that DEF has a default constructor generated for it by the
compiler and in accordance with the C# specification, and that the
default constructor calls the base's parameterless constructor. (In C#,
every constructor chain within a class other than object terminates at
some stage with a call, implicit or explicit, to one of the
constructors of the base class.)

How would you describe the following behaviour, in that you get a
compile-time error, without saying that DEF *doesn't* inherit the
constructor?

using System;

class ABC
{
public ABC (int x)
{
}
}

class DEF
{
}

class Test
{
static void Main(string[] args)
{
DEF def = new DEF(10);
}
}

See http://www.pobox.com/~skeet/csharp/constructor.html for a more in-
depth discussion.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #13

P: n/a
Hold on, I wasn't trying to disagree with ya, just trying to clarify things
in my head. I had seen the behavior you demonstrated as well, which made it
sort of appear there was inheritance in one case and not in the other.

What you say makes sense, except for the part in parenthesis - I did not
know that. What's the point of being able to specify a base class
constructor to be called in the subclass constructor - to override what the
compiler may choose to do by default?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:
Jon, how would you describe the following behavior, in that
DEF._someInteger will = 20 , without saying DEF inherits the
constructor?
I would say that DEF has a default constructor generated for it by the
compiler and in accordance with the C# specification, and that the
default constructor calls the base's parameterless constructor. (In C#,
every constructor chain within a class other than object terminates at
some stage with a call, implicit or explicit, to one of the
constructors of the base class.)

Nov 15 '05 #14

P: n/a
Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:
Hold on, I wasn't trying to disagree with ya, just trying to clarify things
in my head.
Fair enough :)

(This is a topic it's easy to get me riled up about, I'm afraid. There
was an ugly argument about whether or not constructors were inherited,
despite the spec absolutely *explicitly* stating that they're not.)
I had seen the behavior you demonstrated as well, which made it
sort of appear there was inheritance in one case and not in the other.

What you say makes sense, except for the part in parenthesis - I did not
know that. What's the point of being able to specify a base class
constructor to be called in the subclass constructor - to override what the
compiler may choose to do by default?


Well, sort of. If you don't specify anything, it's the equivalent of
having base() - but you may well want to specify a different one, or
indeed there may *be* no parameterless constructor in the base class to
be called automatically.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.