EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Making a case for cases
From: Tim Mooney <[email protected]>
To: [email protected]
Date: Thu, 05 Aug 2010 17:43:51 -0500
I always have a problem running capitalized acronyms into a capitalised sub
word, and I usually end up sticking in an underscore for clarity.
For example, how would you distinguish MPS_Trip from MP_Strip?

Tim Mooney

On 8/5/2010 5:00 PM, Steiner, Mathias wrote:
Thanks for all the replies!

There seems to be consensus on a few fronts; let me sum up what I learned.


(i) People seem to favor mixed case for readability. The main concerns are searchability/uniqueness and how to standardize.

I think the question of standardizing names is separate from case, and has to be addressed in any event.


(ii) Use of Separators.


For us, this has been decided. The FRIB convention states that only alphanumberic characters are to be used, with the exception of ":" and "_".

The colon is only allowed to separate the various parts of the name; the underscore is only allowed to separate system from subsystem and device from instance.

That automatically limits the possibilities for our example:

DTL_Diag:BLM_n130:MPSTripLimitRad or
DTL_DIAG:BLM_N130:MPSTRIPLIMITRAD or
dtl_diag:blm_n130:mpstriplimitrad

I think mixed case becomes essential when separators can't be used.


(iii) David Purcell makes an excellent point about having rules and following them.


We have the same issue at NSCL, where engineers and technicians name things as they build them, and since they usually aren't told what the names are supposed to be, they make them up on the spot.

I believe the solution is to have project leaders design the names into the system from the start. This might even make them think about controls ahead of time ;->

There needs to be an authority to make sure the proposed names pass muster. ":HVRd" isn't really worse or better than ":RdHV," but we don't want both.

A small committee might be indicated; I envision three or four people from different departments, preferably the kind who hate meetings...

Thanks again for the discussion... it made things a lot clearer.

Cheers -Mathias



-- Tim Mooney ([email protected]) (630)252-5417 Software Services Group, Advanced Photon Source, Argonne National Lab.

Replies:
Re: Making a case for cases Ralph Lange
References:
medm Mezger Anton-Chr.
Re: Making a case for cases Steven M. Hartman
Re: Making a case for cases Purcell, J. David
Re: Making a case for cases Andrew Johnson
RE: Making a case for cases Steiner, Mathias

Navigate by Date:
Prev: Re: Making a case for cases Ralph Lange
Next: Re: Making a case for cases Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Making a case for cases Ralph Lange
Next: Re: Making a case for cases Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·