A couple questions of style

[Daniel Billingsley]

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.

[Dmitriy Lapshin [C# / .NET MVP]]

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**********@N O.durcon.SPAAMM .com> wrote in message
news:%2******** **********@tk2m sftngp13.phx.gb l... 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.

[Jeffrey Tan[MSFT]]

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.

[Jeff Louie]

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!

[Kevin Cline]

"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in message news:<##******* *******@tk2msft ngp13.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".

[Eric Newton]

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******@hotma il.com> wrote in message
news:ba******** *************** ***@posting.goo gle.com...

"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in message

news:<##******* *******@tk2msft ngp13.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".

[Frank Oquendo]

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)

[Alvin Bruney]

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****@acadxpi n.com> wrote in message
news:uO******** ******@TK2MSFTN GP12.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)

[Daniel Billingsley]

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********@yah oo.com> wrote in message
news:e5******** ******@TK2MSFTN GP12.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!

[Daniel Billingsley]

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****@acadxpi n.com> wrote in message
news:uO******** ******@TK2MSFTN GP12.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.