What is a good naming convention for a routine that sets a global variable in the same class

Question

Code Complete (Chapter 7, Section 3) says that a good function should be named for the value it returns and a good procedure name in a class should be named for what it does.

When I write synchronized methods in Delphi (pre 2009) I sometimes need to use them to set global variables, a seemingly bad programming practice, but a necessary once since I can't pass variables. I don't want to call them "Get" or "Set" because I use those for my property methods.

Anyone have a better naming convention for these?

Answer 1

I don't want to call them "Get" or "Set" because I use those for my property methods.

That seems like a pretty arbitrary decision. Might you also say you don't want to use "set" on "setName" because you also used it on "setAge"?

That said, having a static with a setter is literally a public global variable ALA Basic-- Are you sure that's the only way to accomplish your mission?

I'm not saying the static is absolutely wrong, but you should do your best to manipulate it in the object that defines it rather than having a setter, otherwise your exposing a lot of your object's internal state in a way that's going to be hard to control.

Answer 2

I'd say the advice from Code Complete is pretty strong and your objection "because I use those for my property methods" is pretty weak. Those property setter/getters should be private anyway. Consider it a form of overloading and call them SetFoo and GetFoo.

Answer 3

What Delphi version are you using? If using D2006 or 2007 you can move the globals into class properties with class methods to get and set the values. As these are property getters and setters, using Get and Set are appropriate.

type
 TMyObject = class(TObject)
 private
    class var
      FStringProperty : string;

    class function GetStringProperty: String; static;
    class procedure SetStringProperty(const Value : string);static;
  public
    class property StringProperty : String read GetStringProperty write SetStringProperty;
  end;

Answer 4

Property getters and setters don't have names starting with get and set because it's some convention reserved for naming getters and setters. They have those names because that's what they do . Since your synchronized method's purpose is to set the value of a variable, it makes perfect sense to give it a "set" name.

You could choose a synonymous verb, like assign or copy , just to be different from set , but those are unconventional names for the purpose you've described. When you have a routine that sets the value of Foo , convention dictates that the function must be named SetFoo . Ultimately, I think you just need to get over whatever hangup you have about using get and set for things that aren't property accessors.

Answer 5

In my opinion writing to global variables should be easily distinguishable from normal setters. If a global variable cannot be avoided I normally use

SetGlobalFoo(...);

for this purpose. The overhead for the long name is OK IMO because these constructs should be rarely used.

Answer 6

I would use SetXXX and GetXXX for private and global variables because I don´t see a difference in what those methods do. The operation to SetXXX is a set over a data area. If that data area is global, local or remote, it´s an internal detail of the method that should not be visible from outside.

The IDE will help you to know if that data area is local or not, but if you prefer, you can write a simple line of comment stating it.