what's the idea behind the commonly used oDoc, oRule, sText, and oColl in code

[janrienk]

I often come across names like these in code: oDoc, oRule, sText and oColl. I was wondering what the idea behind this is. Perhaps it is because I don't have a lot of experience in programming yet, but I don't find it easy to read. Wouldn't it make the code easier to read if the names were a bit more descriptive?

For instance, I find this a lot harder to read:

Dim oAsmDoc As Inventor.AssemblyDocument = ThisDoc.Document
Dim oPars As Inventor.Parameters = oAsmDoc.ComponentDefinition.Parameters

Dim oList As Collection = New Collection
For Each oPar As Inventor.Parameter In oPars
    If (Left(oPar.Name, 2) = "G_") Then
        oList.Add(oPar.Name)
    End If
Next

Than this:

Dim this_document As Inventor.AssemblyDocument = ThisDoc.Document
Dim own_parameters As Inventor.Parameters = this_document.ComponentDefinition.Parameters

Dim own_global_parameters As Collection = New Collection
For Each own_parameter As Inventor.Parameter In own_parameters
    If (Left(own_parameter.Name, 2) = "G_") Then
        own_global_parameters.Add(own_parameter.Name)
    End If
Next

Thoughts/feedback appreciated.

[-niels-]

I'm not much of a programmer myself either, but i've read somewhere that that "o" stands for "object" and as such helps programmers identify what they're dealing with.
It is a standard practice, but unless you're a "real" or at least more experienced programmer it  doesn't make a lot of sense.

@Curtis_Waguespack, can you give a more detailed reason for this practice?

[Anonymous]

As -niels- stated, it's to represent that the variable contains an instance of an object.  It's kind of this: https://en.wikipedia.org/wiki/Hungarian_notation

and it can be handy - you know if it starts with a lower case "o" it's something you made.  This doesn't matter much when your program fits on one page, but once you hit a few thousand lines of code, it's very nice to have a standard system of naming what things are.

[Curtis_Waguespack]

Hi @janrienk,

In addition to the previous replies, see this link:

https://forums.autodesk.com/t5/inventor-customization/ilogic-a-couple-syntax-questions/m-p/6407238#M...

Also just as a tip, you can search and ask programming questions of this type on the Inventor Customization forum too:
http://forums.autodesk.com/t5/Autodesk-Inventor-Customization/bd-p/120

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[dgorsman]

When you didn't have automatic type checking knowing the type based on the prefix was useful.  Similarly using a plain-text or limited editor without auto-complete, auto-warning of unused or undeclared variables, etc. keeping the names short and easy to type helped reduce the chance for typo-based errors.  And when you had limited space to work with, functions were limited in scope, and the code was only exposed to dedicated programmers extensive comments were considered wasteful.

A lot has changed since then, there's a lot of automation in IDE's which now handles that for you.  There's no problems with verbose naming just be consistent and rational in your naming and capitalization .e. part_label_text shouldn't be an integer, loop_counter shouldn't be a string, and so on.  I'd still recommend extensive comments; with a few thousand lines of code, reconstructing the overall logic from variable names alone is going to be hard regardless of what naming system is in use.

[Anonymous]

@dgorsman yes - agreed many comments are good.  no matter how clear code was when you made it, it will make sense to no one after 6 months; and documentation just doesn't happen unless that's your job.

[janrienk]

Well, it looks like I'm doing something wrong then. Inventor's interface for making these rules seems to have none of the goodies you describe. Even when I select a variable name and hit crl+f the find/replace interface doesn't fill up the "find what" field with my selected text XD.

I must object though to extensive commenting. I think comments can be useful, but I want the code to speak for itself as much as possible. At the moment I'm the most familiar with iLogic (or any programming) in my current company, and I'm starting a new job in January. I'm afraid no one will be able to make heads or tails of the code if I don't make it descriptive. Is it really verbose if it needs extensive commenting?

[dgorsman]

While the code itself provides a low-level description of what's happening at any specific point, it doesn't provide a top-level understanding of what's going on.  That's the job of comments - they don't duplicate what's in the code, but rather document the overall flow and logic so someone can quickly skim them (in natural language format) rather than reconstructing from the variables, functions, and operators.