|
Visual Studio 2013 for windows 8.1 apps
|
|
|
|
|
And what does that have to do with what I said??
|
|
|
|
|
That's the compiler and libraries used for the code.
|
|
|
|
|
Considering I wasn't commenting on that at all, your post makes no sense.
I was merely commenting that the compiler is never responsible for supporting the application, YOU are.
|
|
|
|
|
I see yes the context of how someone takes a sentence is important.
The code is flawless, again the question was about coding practices.
|
|
|
|
|
When I commented on this branch of the thread, it wasn't addressed to you.
|
|
|
|
|
Its valid code.
Coding practices is the topic.
|
|
|
|
|
Colborne_Greg wrote: Coding practices is the topic
Coding practices are a form of communication to the next developer to assist them in their understanding of the code. There are no absolutes -- a syntax acceptable to one group might not be acceptable to another group. In general though, use of an oddball syntax in one place in the code is a poor practice.
So, the only realistic answer to your question is "it depends". It depends on whether that's the common syntax used throughout the rest of the code, or an oddball one.
Colborne_Greg wrote: Its valid code
I have three words by way of countering this line of thought: Obfuscated C Contest.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I keep a common structure, thank you for a straight answer.
|
|
|
|
|
I don't see any problem with it, as a matter of fact it actually reminds me of C++ member declaration.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
|
"It is a vessel of fertilizer, and none may abide its strength."
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Refrain for abusive comments
|
|
|
|
|
Refrain from abusive code.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
At a first glance, I find this confusing. In particular because the DataMember attribute actually accepts a constructor parameter.
- So if I set the constructor parameter, which field does it apply to?
- Likewise, if you want to switch out serializers and use something like Protocol Buffers this syntax simply won't translate. You would need to break out each one as the constructor is required.
- On top of this all, there's a mixing of types. I'm not a big fan of the "multi-declaration" syntax, especially when it doesn't save any actual lines like this example. But there are some cases where it is useful. That stated, if you're mixing types on the "multi-declarations", it's time split them out.
I wouldn't call this "unacceptable" practice, especially in the context of firing someone over this. I would however call this "non-standard" and "confusing" and ask that it be changed.
|
|
|
|
|
This is what it looked like before
<System.Runtime.Serialization.DataMember>
Private mLastUpdated As DateTime
<System.Runtime.Serialization.DataMember>
Private mLastUpdatedBy As String
<System.Runtime.Serialization.DataMember>
Private mClearanceRequired As Int64
<System.Runtime.Serialization.DataMember>
Private mClearanceIsRequired As Boolean
The first example I wrote, stands on in the document, where writing datamember so many times with the word private seems to be a waste of space.
|
|
|
|
|
So to clarify, you're saying that "saving space" is more important than "providing clarity" and "avoiding bugs"?
If you're trying to save space why are you:
1. Using Private at all? That's the default, just take it out.
2. Using that little "m" in the prefix. Why not just lower-case the first letter? ("lastUpdated")
3. Using full words when you could abbreviate everything? ("lstUpd")
4. Not importing the System.Runtime.Serialization on the file? Then you could just type "<datamember>"!
If "saving space" is really important, why aren't you doing it everywhere?
And at the end of the day, all of this code is functionally equivalent, right? So it all compiles to the same IL.
I'm just not understanding the "save space" argument here.
|
|
|
|
|
The word Private indents the code for white space.
The m stands for Member some companies use an underscore _ instead, each data member has a corresponding property that exposes the data member with extra code for validation, each of these properties implement an interface.
The intent is white space and readability not saving space.
Importing a class file is improper name resolution
|
|
|
|
|
Quote: ...datamember so many times with the word private seems to be a waste of space.
Your own words literally say that you are worried about "wasting space". Now you've changed it slightly:
Quote: The intent is white space and readability not saving space.
You're worried about "wasting space" but only for some very specific and narrow scope of "wasting". And in this particular case, you're worried about "small waste" vs. "absolute clarity" which seems like a pretty lame trade-off.
The fact that anyone had to question whether or not the attribute applied to all the variables means that you failed the "readability" test. Your goal of "readability" actually resulted in this code being hard to read and possibly being "unclear" to people who were not experts in this very narrow language feature.
|
|
|
|
|
you are right I did say waste of space.
|
|
|
|
|
I am way out to left field my own practices are just for myself as I am the owner of my software company.
This is the whole thing, I already know how off standard this is.
Namespace Sinks
<System.Runtime.Serialization.DataContract(IsReference:=True)>
Public MustInherit Class Base
Inherits Validate
Implements iInterface
<System.Runtime.Serialization.DataMember>
Private mLastUpdated As DateTime, _
mLastUpdatedBy As String, _
mClearanceRequired As Int64, _
mClearanceIsRequired As Boolean
Public Sub New()
MyBase.New()
End Sub
Public Sub New(Clearance As Int64)
MyBase.New()
ClearanceRequired = Clearance
End Sub
Public Property LastUpdated As DateTime Implements iInterface.LastUpdated
Get
Return mLastUpdated
End Get
Set(value As DateTime)
mLastUpdated = value
End Set
End Property
Public Property LastUpdatedBy As String Implements iInterface.LastUpdatedBy
Get
Return mLastUpdatedBy
End Get
Set(value As String)
mLastUpdatedBy = value
End Set
End Property
Public Property ClearanceIsRequired As Boolean Implements iInterface.ClearanceIsRequired
Get
Return mClearanceIsRequired
End Get
Set(value As Boolean)
mClearanceIsRequired = value
End Set
End Property
Public Property ClearanceRequired As Long Implements iInterface.ClearanceRequired
Get
Return mClearanceRequired
End Get
Set(value As Long)
mClearanceIsRequired = True
mClearanceRequired = value
End Set
End Property
Public Overloads ReadOnly Property Value(User As Directory.iUser) As Object Implements iInterface.Value
Get
Select Case True
Case User.Deny : Throw New Exception("User Denied!")
Case ClearanceIsRequired And User.ClearanceReadLevel < ClearanceRequired : Throw New Exception("User clearance is lower then required!")
Case Else : Return MyBase.Value
End Select
End Get
End Property
Public Overloads WriteOnly Property Value(UpdatedDate As Date, LastUpdatedBy As String) As Object Implements iInterface.Value
Set(value As Object)
Me.LastUpdated = UpdatedDate
Me.LastUpdatedBy = LastUpdatedBy
MyBase.Value = value
End Set
End Property
Public Overloads WriteOnly Property Value(UpdatedDate As Date, LastUpdatedBy As Directory.iUser) As Object Implements iInterface.Value
Set(value As Object)
If Me.LastUpdated = Nothing Then Me.LastUpdated = Me.Created
Select Case True
Case ClearanceIsRequired
LastUpdatedBy.Authorize _
(
OriginalDate:=Me.LastUpdated,
ChangeDate:=UpdatedDate,
ClearanceLevel:=Me.ClearanceRequired
)
Case Else
LastUpdatedBy.Authorize _
(
OriginalDate:=Me.LastUpdated,
ChangeDate:=UpdatedDate
)
End Select
Me.Value(UpdatedDate, LastUpdatedBy.Name) = value
End Set
End Property
End Class
End Namespace
modified 14-Apr-14 16:05pm.
|
|
|
|
|
I would prefer to write the attribute for each member, if you want to save lines of code you could write them inline.
<System.Runtime.Serialization.DataMember> Private mLastUpdated As DateTime
<System.Runtime.Serialization.DataMember> Private mLastUpdatedBy As String
<System.Runtime.Serialization.DataMember> Private mClearanceRequired As Int64
<System.Runtime.Serialization.DataMember> Private mClearanceIsRequired As Boolean
And since you're saving lines of code, why could use auto-implemented properties por LastUpdated, LastUpdatedBy and ClearanceRequired.
|
|
|
|
|
yeah I like that way too.
It's not about saving lines of code, it's about creating white space
|
|
|
|
|
If you're worried about space, why are you using one of the most verbose languages there is? 
|
|
|
|
|
White space and readability
It's like taking actual English practices and applying them to coding, so the point reading code is like reading a paragraph - when it's so elegant writing comments are redundant.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
