On Naming and Such
So, we’ve been having a discussion around the office on what should be our standard, if any, regarding naming conventions, and when to use objects and sub-objects rather than to just use the full context of the objects. I might be using the wrong terminology here, but here’s an example of what I mean. What’s the difference between the following two sets of code?
Private oSAPAPI As SAPConnection
Dim oOrder As SAPbobsCOM.Documents = oSAPAPI.Company.GetBusinessObject(SAPbobsCOM.BoObjectTypes.oOrders)
oOrder.GetByKey(“1”)
oOrder.Lines.SetCurrentLine(1)
If oOrder.Lines.ItemCode = “foo” Then
MsgBox(“Foo!”)
End If
Private oSAPAPI As SAPConnection
Dim oOrder As SAPbobsCOM.Documents = oSAPAPI.Company.GetBusinessObject(SAPbobsCOM.BoObjectTypes.oOrders)
oOrder.GetByKey(“1”)
Dim oOrderLines As SAPbobsCOM.Document_Lines = oOrder.Lines
oOrderLines.SetCurrentLine(1)
If oOrderLines.ItemCode = “foo” Then
MsgBox(“Foo!”)
End If
Technically, they would serve the exact same function, yes? But the difference is that we’re creating an additional object that needs to be managed. That takes up more resources, yes. I’m not sure whether or not there’s been any research done on the cost expenditure of these resources, but I would expect them to be negligible.
I would prefer the latter method of writing code to the former. Why? Because I like compartmentalization and encapsulation, and separating things out into pieces. I also like for my codelines to be shorter horizontally, though it may cause the code to have more overall lines. I just find it easier to read. For another example, take this nested method:
Dim dInput As Decimal = Math.Round(Convert.ToDecimal(“45.069023”), 2)
So, that’ll convert the string into a decimal, and then round it off to two decimal places. But I hate this. I would prefer the following code:
Dim sInput As String = “45.069023”
Dim dInput As Decimal = 0.0
Decimal.TryParse(sInput, dInput)
If dInput <> 0.0 Then
dInput = Math.Round(dInput, 2)
End If
Why? Multiple reasons:
- It doesn’t go halfway across the screen horizontally, which is more pleasing to my eyes
- It gives me more possible breakpoints for debugging in case something goes wrong
- It gives me more places to put Watch Points in Visual Studio to watch for the value of the variables as they go through the different methods, bit by bit
Yes, I’m aware that I’m creating an additional unnecessary variable that takes up a little bit more memory. Yes, I’m aware that I’m creating additional lines of what could be considered unnecessary code, but I like having the extra debug space to work around in, and I think it makes it easier to solve problems with code when it’s broken down like this.
So, what say you? Do you agree with me, or do you think it’s just extra overhead that’s not necessary? Why?
Hi Westley,
This line:
Dim oOrderLines As SAPbobsCOM.Document_Lines = oOrder.Lines
doesn't create a new object. It creates a reference to an already existing object. In terms of resources it means storing a reference (its pretty much negligible). But one can use a memory profiler to check numbers.
In the SDK we have COM components and there is a slight overhead in "communicating" with these components. Storing a reference like that can have a positive effect especially on collections (such as document lines).
for(...)
{
document.Lines.ItemCode="ItemCode"; // hits performance when there are many lines
}
var lines = document.Lines;
for(...)
{
lines.ItemCode="ItemCode"; // better
}
There are some post in SCN about this where some experienced an improvement in speed.
Regarding your second point, for me readability is a major point and this:
Dim sInput As String = "45.069023"
Dim dInput As Decimal = 0.0
Decimal.TryParse(sInput, dInput)
If dInput <> 0.0 Then
dInput = Math.Round(dInput, 2)
End If
Reads far better than the alternative. Source code should be written for Humans not for machines (that's the compiler job).
That's my 2 cents 😉
Cheers.
Best regards,
Pedro Magueija
Another 2 cents,
With regards of declaring
Dim oOrderLines As SAPbobsCOM.Document_Lines = oOrder.Lines
I read in SDK documentation -somewhere, which I could not find it anymore-
When using
oOrder.Lines.ItemCode = "XXX"
Internally, a reference of the SAPbobsCOM.Document_Lines was created.
But you could not access this reference object from your code since you didn't declare it.
The implication is :
When doing house cleaning of your memory using the ReleaseComObject, you can only release the oOrder object. The reference for the document_lines is not released, thus resulting in a memory leak.
By declaring the oOrderLines as SAPbobsCOM.Document_Lines, you can explicitly release this com object.
ReleaseComObject(oOrderLines)
ReleaseComObject(oOrder)
Resulting in a more managed memory
So, with regards to your comment
It is not a downside, actually it is so that we can manage the resource.
Having said that, Yes, I agree with you to better declare the oOrderLines.
Eventhough I confess that I always use the 'oOrder.Lines.ItemCode' 🙂
Regards
Edy