Reply to thread

Message

on public vs private fields and properties and all

Myself I have come to prefer in stead of this:

public class SomeClass
{
private int m_Playlist;

public int Playlist { get { return m_Playlist; } set { m_Playlist = value; } }
}

public class SomeClass
{
private int m_Playlist;

public int Playlist
{
get { return m_Playlist; }
set { m_Playlist = value; }
}
}

This way of indenting and whitespacing in our coding peoples opinion seems to allow readability whilst not one-lining stuff just like above.
A bit shorter than Frodo's recommended way, which I guess one should use when playing with his stuff, on the other hand thicker than the one-lined.

I guess it kind of comes down to what one is used to reading, if it were all UML than it would be kind of obvious.
I mean logically it's all the same construct anyway.

Some people (devs or almost people anyway=) seem to like separating things like this:
//private vals
#region PrivateInternallyUsables
private int m_streamSpeed; // integer for stream thickness in bytes
private int m_transferBufferSize; //int for stream transfer buffer size in bytes
#endregion

//public accessors
#region Accessors
public int StreamSpeed
{
get{;}
set{;}
}
public int TransferBufferSize
{
get{;}
set{;}
}
#endregion

In the end, I feel one should use what one is comfortable with.
BUT; following the guidelines laid down by the holiest of holies, the person , responsible for the project. In this case I guess Frodo. Because essentially when you have a point, he will pick it up and put it in the next version of the guidelines.

<blockquote data-quote="Myyz" data-source="post: 16060">on public vs private fields and properties and allMyself I have come to prefer in stead of this:public class SomeClass{&nbsp; private int m_Playlist;&nbsp; public int Playlist { get { return m_Playlist; } set { m_Playlist = value; } }}public class SomeClass{&nbsp; private int m_Playlist;&nbsp; public int Playlist&nbsp; {&nbsp;&nbsp; get { return m_Playlist; }&nbsp;&nbsp; set { m_Playlist = value; } &nbsp; }}This way of indenting and whitespacing in our coding peoples opinion seems to allow readability whilst not one-lining stuff just like above.A bit shorter than Frodo's recommended way, which I guess one should use when playing with his stuff, on the other hand thicker than the one-lined. I guess it kind of comes down to what one is used to reading, if it were all UML than it would be kind of obvious.I mean logically it's all the same construct anyway. Some people&nbsp; (devs or almost people anyway=) seem to like separating things like this://private vals#region PrivateInternallyUsablesprivate int m_streamSpeed; // integer for stream thickness in bytesprivate int m_transferBufferSize; //int for stream transfer buffer size in bytes#endregion//public accessors#region Accessorspublic int StreamSpeed{get{;}set{;}}public int TransferBufferSize{get{;}set{;}}#endregionIn the end, I feel one should use what one is comfortable with. BUT; following the guidelines laid down by the holiest of holies, the person , responsible for the project. In this case I guess Frodo. Because essentially when you have a point, he will pick it up and put it in the next version of the guidelines.</blockquote>

[QUOTE="Myyz, post: 16060"] [b]on public vs private fields and properties and all[/b] Myself I have come to prefer in stead of this: public class SomeClass { private int m_Playlist; public int Playlist { get { return m_Playlist; } set { m_Playlist = value; } } } public class SomeClass { private int m_Playlist; public int Playlist { get { return m_Playlist; } set { m_Playlist = value; } } } This way of indenting and whitespacing in our coding peoples opinion seems to allow readability whilst not one-lining stuff just like above. A bit shorter than Frodo's recommended way, which I guess one should use when playing with his stuff, on the other hand thicker than the one-lined. I guess it kind of comes down to what one is used to reading, if it were all UML than it would be kind of obvious. I mean logically it's all the same construct anyway. Some people (devs or almost people anyway=) seem to like separating things like this: //private vals #region PrivateInternallyUsables private int m_streamSpeed; // integer for stream thickness in bytes private int m_transferBufferSize; //int for stream transfer buffer size in bytes #endregion //public accessors #region Accessors public int StreamSpeed { get{;} set{;} } public int TransferBufferSize { get{;} set{;} } #endregion In the end, I feel one should use what one is comfortable with. BUT; following the guidelines laid down by the holiest of holies, the person , responsible for the project. In this case I guess Frodo. Because essentially when you have a point, he will pick it up and put it in the next version of the guidelines. [/QUOTE]