Tag Info

New answers tagged

3

While I generally agree with dan1111's answer, there is one particularly important case it does not cover: the case where smartphone is used concurrently. In that scenario, this sort of pattern is a well known source of hard to find bugs. The problem is that short circuit evaluation is not atomic. Your thread can check that smartphone is null, another ...


2

One consideration, not mentioned in other answers: sometimes having these checks can hint at a possible refactoring to the Null Object design pattern. For example: if (currentUser && currentUser.isAdministrator()) doSomething(); Could be simplified to just be: if (currentUser.isAdministrator()) doSomething (); If currentUser is defaulted ...


7

You can take this further, and in some languages it's the idiomatic way to do things: you can use short circuit evualuation outside of conditional statements too, and they become a form of conditional statement themselves. E.g. in Perl, it is idiomatic for functions to return something falsy on failure (and something truthy on success), and something like ...


-6

I'm going to be unpopular and say Yes, it is bad practice. IF the functionality of your code is relying on it to implement conditional logic. ie if(quickLogicA && slowLogicB) {doSomething();} is good, but if(logicA && doSomething()) {andAlsoDoSomethingElse();} is bad, and surely no-one would agree with?! if(doSomething() || ...


20

Let's say you were using a C-style langugage with no && and needed to do the equivalent code as in your question. Your code would be: if(smartphone != null) { if(smartphone.GetSignal() > 50) { // Do stuff } } This pattern would turn up a lot. Now imagine version 2.0 of our hypothetical language introduces &&. Think how cool ...


3

There are plenty of situations where I want to check one condition first, and only want to check a second condition if the first condition succeeded. Sometimes purely for efficiency (because there is no point checking the second condition if the first already failed), sometimes because otherwise my program would crash (your check for NULL first), sometimes ...


114

No, this is not bad practice. Relying on short-circuiting of conditionals is a widely accepted, useful technique--as long as you are using a language that guarantees this behavior (which includes the vast majority of modern languages). Your code example is quite clear and, indeed, that is often the best way to write it. Alternatives (such as nested if ...


0

I'm not sure if the calibration should be the responsibility of the sensor... I would consider creating 2 new classes. Something like SensorCalibratorBase, SensorCalibratorAdavanced. Then, I would create a specific instance of the calibrator based on the app state and feed the sensor instance to it's Calibrate function. Each calibrator would get the needed ...


5

As written (which may be oversimplified) it sounds like the Sensors are all the same in general behavior, but the Parameters for calibration are different. If this were the only difference, and you are using a language with generics, such as Java (used below), you could generify the class by the Parameters, something like: abstract class ...


8

Not if the best descriptive names for these sensors are Sensor1, Sensor2 and Sensor3. The numbers do not indicate any distinguishing characteristics between the sensors. If the different classes denote different types of sensors, then different classes may be warranted. This is why we sometimes refer to classes as types, though the word "type" itself has ...



Top 50 recent answers are included