Skip to Content

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:

  1. It doesn’t go halfway across the screen horizontally, which is more pleasing to my eyes
  2. It gives me more possible breakpoints for debugging in case something goes wrong
  3. 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?

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Pedro Magueija

    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

    View Pedro Magueija's profile on LinkedIn

    (0) 
  2. Edy Simon

    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

    But the difference is that we’re creating an additional object that needs to be managed


    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


    (0) 

Leave a Reply