Arrays or idividual names

Recently I started to recode my model roller coaster project to be able to operate with more than one train. A mate of mine offered some help and made his own version of the first part of the code. We put them next to each other and we found out we each have a specific style of coding. Where I prefer to use full names for the sensors on the roller coaster, he just names them sensor[x ] and uses an array and for loop to cycle through the different sensors.

I want to track 3 sensors. All for a specific task on a model roller coaster: one keeps track of the brakes one of the lift and one of the station. My mate says it's better to put the sensors in an array and name them sensor[x ]. To keep the code clean.

I prefer to name them sensorLift sensorBrakes and sensorStation. For me this makes it easier to keep track of what is going on, I want to be able to understand my code when I look at it 6 months later. What do you think?

What is your opinion on this matter? Is an array really worth that much more when I just keep track of 3 sensors?

Ah, evangelistic questions!

I would go for the explicitly named, if the purposes of the sensors are different, you add semantic information to the syntactical jungle. If the sensors would do the same, i.e. your roller coaster got 2 tracks, well, then I would go partly for the arrays (i.e. sensorBrakes[2]).

If you use the same sensors for different purposes then go for a design with a nice class for the sensor type, and the single objects again nicely named. But hey, that is personal opinion (and experience in fixing hundreds of programs which are not written by myself).

If you ever add more sensors you might regret having individual names. Anything to do with doing the same thing to each sensor is easier with arrays, for example:

for (int i = 0; i < MAX_SENSORS; i++)
  InitializeSensor (sensor [i]);

Compared to:

InitializeSensor (sensorLift);
InitializeSensor (sensorBrakes);
InitializeSensor (sensorStation);

Things just get worse if you have more than three, and already they are more complex. But if you sometimes do something to one, and sometimes to the other, maybe you haven’t gained much with arrays. You can compromise and keep readability, like this:

#define LIFT 0
#define STATION 1
#define BRAKES 2

InitializeSensor (sensor [LIFT]);
InitializeSensor (sensor [STATION]);
InitializeSensor (sensor [BRAKES]);

Now if you ever need to do something to one of them you say sensor [STATION] which is more readable than sensor [1] and not much worse than sensorStation.

I'd go for Nick's last suggestion, both readable and scalable.


Rob

Well, what kind of thing is sensor? If it is an object, what does InitializeSensor do and how does it know to do it?
This design supposes that the lift, station and brakes sensors are of the same kind which is not clearly stated in the original post which says: All for a specific task. That they are sensors doesn’t qualify them to treat them exactly the same.
Maxlaam gave also another clue: …when I just keep track of 3 sensors?.
Some designs are never intended to scale; think about the serial interface or an external display, you will have 1 and never intend to scale it, if you design scalability on these you loose time.

I still think (in this very specific case) a readable K.I.S.S design is better than putting a new dimension and a superfluous keyword (sensor) where none is needed.

As for readability, again, i’d prefer to read a straightforward OOC

brakes.initialize(); 
brakes.isActive(); 
brakes.reset(); // etc.

in contrast to:

initialize(sensors[BRAKES]); 
if (isActive(sensors[BRAKES])){} // ...
reset(sensors[BRAKES]);

putting spaces will not enhance the readability (as in the latter case you will go through the single line in reverse).
The reading effort is higher (you got brakes, what do i do? initialize) <–> (Initialize, initialize what? a sensor, which sensor?, brakes)

Now, let’s suppose we want to scale the sensors in this simple scenario. We get a multitrack rollercoaster, with n-brakes.

the design will be how?

initalize(sensors[BRAKES1]); 
if (isActive(sensors[BRAKES1])){} // ...
reset(sensors[BRAKES1]);
initalize(sensors[BRAKES2]); 
if (isActive(sensors[BRAKES2])){} // ...
reset(sensors[BRAKES2]);
//etc...

or with a multidimensional array? But what if only the brakes needed to be scaled as the station is one only?

for (int i=0; i < N; i++) {
   initialize(sensors[BRAKES][i]); // 
   if (isActive(sensors[BRAKES][i])) {} // ...
   reset(sensors[BRAKES][i]);
}

and the scaling of the OOC

for (int i=0; i < 2; i++) {
   brakes[i].initialize(brakepins[i]); 
   if (brakes[i].isActive()) {} // ... 
   brakes[i].reset(); 
}
#define LIFT 0

#define STATION 1
#define BRAKES 2

and still some more food for thought: wouldn’t it be better to define the constants with an enum, so while you scale it you don’t need to bother about the actual value?

JM2C
P.S.: i am not advocating to use OOP in this case, the specs of the project are insufficient to make a ‘good’ decision.

scjurgen: and still some more food for thought: wouldn't it be better to define the constants with an enum, so while you scale it you don't need to bother about the actual value?

Absolutely. I was being lazy, plus not trying to introduce too much new stuff at once. With an enum you also get the maximum as a side-effect. eg.

enum {
      LIFT,    
      STATION,  
      BRAKES, 

      // add more here ...


      // This must be last !!!
      MAX_SENSORS
  };

Now if you add new ones after BRAKES but before MAX_SENSORS, then MAX_SENSORS will always be the total number of them.