Author Topic: variable names  (Read 4669 times)

0 Members and 1 Guest are viewing this topic.

MickD

  • King Gator
  • Posts: 3648
  • (x-in)->[process]->(y-out) ... simples!
Re: variable names
« Reply #15 on: October 15, 2015, 05:16:44 PM »
My default is to spell it out with variables as camel casing, constants as all caps, and everything else as Pascal casing.  The exception is everyday Autodesk variables, i.e. doc, db, bt, ms, tr, etc.

Prefixes like p, m, and _ are a C++ thing and I leave them there.

ditto ^^

In regards to var names with type prefix, I agree it's not needed and give the variables a name like fileName, fileCount, fileType etc so it makes sense to what type they are.
I also like to keep methods as small as possible so short var names are less of an issue due to the small scope, if you use small var names in a mammoth method it's easy to get confused.
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

gile

  • Gator
  • Posts: 2520
  • Marseille, France
Re: variable names
« Reply #16 on: October 15, 2015, 05:43:54 PM »
Quote
I also like to keep methods as small as possible so short var names are less of an issue due to the small scope, if you use small var names in a mammoth method it's easy to get confused.
+1
I usally use single letter var names in lambda expressions.
Speaking English as a French Frog

MexicanCustard

  • Swamp Rat
  • Posts: 705
Re: variable names
« Reply #17 on: October 16, 2015, 01:18:43 PM »
I usally use single letter var names in lambda expressions.

This too!  For me it just makes it easier to read.  I don't need to know it's type just knowing its an object of the previous type is enough.
Revit 2019, AMEP 2019 64bit Win 10

CADbloke

  • Bull Frog
  • Posts: 345
  • Crash Test Dummy
Re: variable names
« Reply #18 on: October 18, 2015, 04:08:18 AM »
I usually just type out the entire name to avoid any confusion and to make the code more readable.  So Transaction would become transaction, ObjectId is objectId, etc.  I realize that this is subjective though and a lot of people do not like this style.  I do use abbreviated aliases to avoid namespace collisions however.
I generally type out the whole name but all my screens are huge so long lines are not a problem, well not the problem that my short memory is.
I prefer to be verbose and remove as much ambiguity as I can than to outsmart myself with an abbreviation I need to parse or  I forget when I, or someone else, needs to revisit the code in the distant future.

I'm also often excessively verbose with method names, eg. MakeAbsolutePathFromPossibleRelativePathOrDieTrying(string basePath, string possibleRelativePath). You probably didn't just ask yourself "wtf does that do?".

Can anyone give an example of the `namespace collision' problem and why you would need to use abbreviated aliases?
I concur with the examples already given. I find the aliases the Giles showed are also a handy way to use the same code for different platforms. See http://www.theswamp.org/index.php?topic=49974.msg551546#msg551546. While not strictly necessary in most cases, I find they give a good anchor for the multiple contexts you will be looking at the code in.

mohnston

  • Bull Frog
  • Posts: 305
  • CAD Programmer
Re: variable names
« Reply #19 on: October 21, 2015, 05:17:43 PM »
NOTE: The following is not a useful contribution to this otherwise valuable thread.

I like using oid for ObjectId.
Then prefix with meaningful helper text.
This way my variables get amusing names.

boid, toid, roid

I am easily amused.
It's amazing what you can do when you don't know what you can't do.
CAD Programming Solutions

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: variable names
« Reply #20 on: October 21, 2015, 05:23:31 PM »

< ... >

boid, toid, roid



It scares me a little that that made perfect sense to me   :wink:
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.