4 Replies - 597 Views - Last Post: 05 July 2012 - 07:09 AM

#1 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2041
  • View blog
  • Posts: 4,223
  • Joined: 11-December 07

A variable name dilemma

Posted 05 July 2012 - 04:30 AM

I have recently won a commission to write some code for a scientific group. It happens that the existing software used in that field was designed a long time ago. Back then, the convention was that variable names were highly abbreviated. It makes sense when you consider they were working with a fixed-width format. Some of these abbreviations are more intuitive than others. For example, they had NLAY where I might choose layerNumber and ITMUNI for what I would call timeUnits.

So, I'm left with a dilemma. The code I'm going to write will be used by the same people who use the legacy code. They are mainly scientists, a few of whom will have some coding experience. If I use "timeUnits" then my code would be generally considered more readable but if I use "ITMUNI" it will be closer to what people who are already familiar with existing code in that field will be expecting.

Note that I'm not adding features to an existing program. I'm writing some standalone utilities for them.

I talked the issue over with my boss and we reached a consensus. I thought it would be an interesting point for discussion here though. How would you approach this situation?

Is This A Good Question/Topic? 0
  • +

Replies To: A variable name dilemma

#2 anonymouscodder  Icon User is offline

  • member icon

Reputation: 126
  • View blog
  • Posts: 710
  • Joined: 01-January 10

Re: A variable name dilemma

Posted 05 July 2012 - 05:58 AM

Considering that what you are writing is 'standalone' there would not be so many problems going against their standard.

But normally I would advice to stick with the standard (or convince everybody else to change, writing new code with it and eventually chaging the old one).
Was This Post Helpful? 0
  • +
  • -

#3 tlhIn`toq  Icon User is offline

  • Please show what you have already tried when asking a question.
  • member icon

Reputation: 5566
  • View blog
  • Posts: 11,903
  • Joined: 02-June 10

Re: A variable name dilemma

Posted 05 July 2012 - 06:35 AM

I think you should stick with the Hungarian notation they are used to:

nLay - n is iNteger
szName - sz is string
fYogi - f is float

From there - They brought you in to modernize and rewrite the software. So modernize it. But you can do it in a way that gives them a path of understanding. For example, the backing variable for properties could be their short names.
private int nlay;
public int nLayerNumber
{
    get { return nlay; }
    set { nlay = value; }
}


You're going to have to change large amounts of operation anyway just to have the new software conform to modern OOP and Event-driven principals anyway. Long or short variable names is going to be the least of their concerns regarding understanding your code. With all the architectural differences that will be present, meaningful property and method names will help them.
Was This Post Helpful? 0
  • +
  • -

#4 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 9363
  • View blog
  • Posts: 35,172
  • Joined: 12-June 08

Re: A variable name dilemma

Posted 05 July 2012 - 07:01 AM

In terms of name notation - I would make it more readable.. so "timeUnits", but in the documentation you are turning over (and at the top of the code in comments) list that "timeunits" is akin to "ITMUNI".. A translation key or something.
Was This Post Helpful? 0
  • +
  • -

#5 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7869
  • View blog
  • Posts: 13,347
  • Joined: 19-March 11

Re: A variable name dilemma

Posted 05 July 2012 - 07:09 AM

Those conventions don't look much like Hungarian from where I'm sitting - more like old mainframe-style abbreviations in caps. FORTRAN might be the original culprit, I guess. But in any case, the dilemma is a good one.

If there are particular maintainers who will be on the project after you, you should write to their standards, but you should start by talking to them about what that standard actually is, and make that part of the written record. You don't want to start making up stuff that looks like their sort of gobbeldygook and find out later that you just invented a whole new standard which even you can't read.
Writing it down will also make it possible for a future drop-in programmer to help them out.

In the conversation with the long-term code owners, you might mention the possibility of using transparent variable names, see if they go for it, but it's their project, and it's your job to make it easy for them, not the other way around.

If you wanted to be sneaky, I guess, you could make use of global replace. Write it with real variable names and then swap in their sort of garbage before you hand it off, but that would likely create some bugs along the way...
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1