2

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?

Peter Turner
  • 11,199
  • 10
  • 68
  • 109

6 Answers6

3

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.

Bill K
  • 62,186
  • 18
  • 105
  • 157
  • As much as I loathe (Visual) Basic: It does not force or even encourage you to use global variables. That's just the impression you get because of all those bad programmers that use it. – dummzeuch Apr 22 '09 at 05:41
  • Did you see the word Visual anywhere in my post? :) I was talking old-school, there was no way to make a variable anything but global on the basics used in business when I was learning it. – Bill K Apr 22 '09 at 16:24
1

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.

H H
  • 263,252
  • 30
  • 330
  • 514
  • The method he's trying to name should also be private since he's passing it to Synchronize. There's no reason for anything else to call that method except the thread class it's defined in. – Rob Kennedy Apr 22 '09 at 02:37
1

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;
Gerry Coll
  • 5,867
  • 1
  • 27
  • 36
  • 1
    That doesn't really accomplish anything. It's equivalent in every way to using an ordinary global variable. Besides, the Synchronize method can't accept the SetStringProperty method as an argument because it needs to be a zero-parameter method. And global string variables DO need synchronization if they're shared between threads. – Rob Kennedy Apr 22 '09 at 03:55
  • Using Delphi 7, but thanks I'll keep that in mind as we port our code, although with 2009 we'll definitely be using the anonymous methods. – Peter Turner Apr 22 '09 at 13:05
1

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.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
  • It's not that I have a hang-up regarding routine names, I was just wondering if there was a particular convention. I get the same problems with assign (ala class object cloning) and copy (ala memory copying). I just didn't like calling a procedures called getSomething() or setSomething({no params}). – Peter Turner Apr 22 '09 at 13:11
  • I think you DO have hangups about routine names. The "problems" you keep talking about are only problems because YOU'RE making them so. But they really aren't. – Rob Kennedy Apr 22 '09 at 16:35
0

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.

yonojoy
  • 5,486
  • 1
  • 31
  • 60
0

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.

AlexSC
  • 1,823
  • 3
  • 28
  • 54