Coding Standards

General Discussions
#21

[quote]fields are always private, if you need access, a get/set is intended for.
[/quote]
If you have a getter and a setter that get and set the fields directly, your field is public; you might as well declare it public then and skip de getter/setter.
If you have a getter that returns the field directly, your field is basically public and read-only. You might as well declare your field public final then and skip the getter.

Less code, less clutter, better readability, no worries if a slow VM (i.e. dalvik) will not generate sub-optimal code (i.e. optimize away the getters & setters).

In my opinion, a getter is not intended to give you access to a field: A getter should not return a field, but only its value (a copy of it).
And a setter is not intended to give you access to a field, they’re there because it’s the only way in java interfaces to let you set a the value of a field (and again, then for safety you should set the field with a copy).
(Obviously that copying is always done in java with non-objects and object references)

As safe as that is, it can potentially kill performance in games (especially on Android) as copying objects are likely to incur lots of garbage.

#22

The field is an implementation details, the getter is the API.
If you let the caller to use directly the field you can’t rely on an implementation changes without to refactor all usages.

I take by example, if you want to change your implementation for a precise field that you want to set it lazy. You want only to read and instanciate it only when it is accessed.
If you done a getter at the start point, you can reimplement the getter in order to get your lazy function without any impact of the usage.

My position is this

  • You can never have issues to encalupsate a field with getter and setter. (at least no new issue than the direct access version)
  • You can have various issues when letting direct access to your field (that become a API part your class)

So, with this reflexion, i create “get” for all fields if they needs to be publicly accessed outside.

#23

As Cas says: that’s what the refactoring fairy is for. Games are one-shots…you don’t have forward/backward compat issues and N company user base that’s going to be annoyed by breaking changes. Get it done and move on.

#24

Might be true for the game related parts, but not for a game engine (what the thread starter is working on), library or framework.

#25

If you have a getter and a setter that get and set the fields directly, your field is public; you might as well declare it public then and skip de getter/setter.
If you have a getter that returns the field directly, your field is basically public and read-only. You might as well declare your field public final then and skip the getter.

Less code, less clutter, better readability, no worries if a slow VM (i.e. dalvik) will not generate sub-optimal code (i.e. optimize away the getters & setters).
[/quote]
Hmm :/. In 99% of most cases separate getter and setter methods are always better for various reasons:

  1. Others using your object have a clearer understanding what they can do with it.
  2. Backwards compatibility.
  3. You can force someone using your object to use it properly.

That being said, working on my own projects I tend to take the lazy way out <.<

#26

@65K: Depends on design goals and what is exposed to the “end-user”. Take Quake-1. Well lots of folks licensed it…but they aren’t some set of compatible, single runtime games and all changes must work for all. I’m sure that all of them made breaking changes from the ‘trunk’…if you will. Each of the next various Id engines are derived works of the original and none of them are compatible…new stuff went it, older stuff goes away but it’s a constant evolution (some versions more evolutionary than others). All of the various flavors used by all the different licensees are one-shots.

Games are a totally different design space from, say, the standard Java libraries…even when (if) we get jigsaw.

Someone wants to use some updated game engine/library/etc? Well either rewrite the parts you need for breaking changes or stick with the older version you’re using, or go through the PITA of merging new bits you want.

#27

Far too much emphasis is made on binary compatibility in software engineering these days. Come to think of it far too much emphasis is made on source compatibility too. It’s trivial to refactor even a giant project to mitigate massive breakages now. It’s largely the automated work of machines. Embrace change and shifting sands! Your life will get easier once you accept it.

Cas :slight_smile:

#28

See thing works as I desired is the only thing I want. Beauty/reusable/understandable code just bonus.

#29

Making refactoring easier is a good reason to focus on proper interfaces, to hide implementation details and minimize dependencies before.
No one wants to break big business critical systems with costly testing, deployment and downtime phases, with distributed development, with locally customized extensions and lots of interfaces to weird external systems on purpose.
While residing in a smaller software universe, commercial game development is always business critical as well.

#30

When it comes to my game engine I could care less about backward compatibility. Each release I’ll note all public changes. If you want to use the new version you’ll have to update your code! Having said that I’ve been working on a game engine since I was in highschool (7 years now) and my current architecture is definitely what I want and I can’t imagine ever changing it. I think Java will never be able to progress to be a language better than C++ until they say screw backward compatibility and start fresh and add the features people have been requesting for years that have been left out. Many of the core programmers to the Java API have said this as well.

#31

[quote]The field is an implementation details, the getter is the API.
If you let the caller to use directly the field you can’t rely on an implementation changes without to refactor all usages.

I take by example, if you want to change your implementation for a precise field that you want to set it lazy. You want only to read and instanciate it only when it is accessed.
If you done a getter at the start point, you can reimplement the getter in order to get your lazy function without any impact of the usage.
[/quote]
If needed, the direct access can be refactored to a getter in a proper interface with about 3 mouse clicks.
Until then, I just access directly.
(In my own personal little game projects, mind you. When working in teams on larger projects I don’t work that way and stick to the generally accepted coding standards for obvious reasons.)

Sometimes I’d wish java would just let me define a field in an interface without needing to implement getters and setters that basically do nothing.

#32

Scala lets you do this.


class Soldier {

   var facingAngle:Float;
}

thisSolder.facingAngle = 300f;

// Now let's say you want to clamp the value of facing angle between 0 and 360.
class Soldier {

  private var  _facingAngle:Float;


    // EDIT - The  Getter that sproingie pointed out I was missing.
   // (in scala, you do not need an explicit return statement. the function returns the last value.)
   def facingAngle:Float = _facingAngle

  def facingAngle_=(angle:Float) {
      if (angle < 0) _facingAngle = 0
      else if (angle > 360) _facingAngle = 360
      else _facingAngle = angle
   }
}

// Using it

myNewSoldier.facingAngle = 400  // you can refer to it just like a plain old field
println(myNewSoldier.facingAngle)    // prints 360
#33

You didn’t define a getter that accesses _facingAngle, so wouldn’t newSoldier.facingAngle actually return the default value of 0?

Having a language follow the Uniform Access Principle is still pretty keen though :slight_smile:

#34

Thank you and getter is added.