Which is better Which is better n Assume

Which is better?

Which is better? n Assume s 1 and s 2 are Strings: A. if (s 1 == s 2) {. . . } B. if (s 1. equals(s 2)) {. . . } ? 2

Answer: B n n n s 1 == s 2 tests whether s 1 and s 2 reference the same string; s 1. equals(s 2) tests whether they reference equal strings String s 1 = "ABC"; String s 2 = s 1; String s 3 = "ABC"; String s 4 = "AB" + "C" All these strings are equal; but s 4 is in a different memory location than the others, so the == test yields false 3

Which is better? n Assume s 1 is a String: A. if (s 1. equals("OK")) {. . . } B. if ("OK". equals(s 1)) {. . . } ? 4

Answer: B n n s 1. equals("OK") sends a message to s 1 asking if it is equal to "OK". equals(s 1) sends a message to "OK" asking if it is equal to s 1 n n This is legal, because "OK" is a String If s 1 is null, then: s 1. equals("OK") gives a Null. Pointer. Exception "OK". equals(s 1) gives false (Of course, in some circumstances you might prefer to get a Null. Pointer. Exception) 5

Which is best? n Assume int numbers[ ] = new int[100]; A. for (int i = 0; i < 100; i++) numbers[i] = i; B. for (int i = 0; i <= 99; i++) numbers[i] = i; C. for (int i = 0; i < ARRAY_SIZE; i++) numbers[i] = i; D. for (int i = 0; i < numbers. length; i++) numbers[i] = i; ? 6

Answer: D n D is best: for (int i = 0; i < numbers. length; i++) n n C is OK: for (int i = 0; i < ARRAY_SIZE; i++) n n Changing ARRAY_SIZE will fix this loop if array size is changed B is poor: for (int i = 0; i < 100; i++) n numbers. length changes automatically if array size is changed Uses a “magic number” Must track down and change each occurrence if array size is changed A is worst: for (int i = 0; i <= 99; i++) n n This has all the same problems as B B is more traditional and therefore less “surprising” The array size is 100, not 99, so it’s more obvious where the number came from n You have to do some arithmetic to get 99 If you change the array size, a search for 100 won’t find the loop that uses 99 7

Which is better? n Assume finished is a boolean variable: A. if (finished == true) {. . . } B. if (finished) {. . . } ? 8

Answer: B n finished == true is redundant: n n n If finished is true, then finished==true will be true If finished is false, then finished==true will be false The extra words don’t gain you anything n n n finished==true might seem more readable to a beginner, but you quickly learn to read the shorter form Brevity in programming, as in writing, is a virtue You can avoid the possible mistake of saying if (finished = true) {. . . } 9

Which is better? n Assume foo, bar, and larger are integers A. if (foo > bar) larger = foo; else larger = bar; B. larger = foo > bar ? foo : bar; ? 10

Answer: neither n n For each of these, you have to look at the code carefully to make sure it is correct larger = Math. max(foo, bar); is easier to read and more obviously correct 11

Which is better? A. String s = "Hello"; B. String s = new String("Hello"); ? 12

Answer: A n n "Hello" is special syntax to implicitly construct a string String s = new String("Hello"); actually constructs two strings: "Hello" constructs the first string, then it is given as a parameter to an explicit constructor, which constructs the second string 13

Which is better? n Suppose p is a JPanel with a Border. Layout and ok. Button is a JButton: A. p. add(ok. Button, Border. Layout. NORTH); B. p. add(ok. Button, "North"); n Note: Border. Layout. NORTH is a String constant whose value is "North" ? 14

Answer: A n n p. add(ok. Button, Border. Layout. NORTH); is strongly recommended over the shorter form p. add(ok. Button, "North") -- but why? Answer: The former gives better error detection n n If you type p. add(ok. Button, "north"), there is no error, but it doesn’t do what you want If you type p. add(ok. Button, Border. Layout. North) you will get a syntax error, because Border. Layout has no such variable as North 15

Which is best? n Suppose n is an int and s is a String: A. s = Integer. to. String(n); B. s = String. value. Of(n); C. s = new Integer(n). to. String(); D. s = n + ""; ? 16

Answer: D n I prefer D (s = n + ""; ) because: n n n It’s a common idiom, therefore easily recognized It’s short It works for any type 17

Which is best? n Assume n is an integer: A. if (n < 0) n = 0; B. if (n < 0) n = 0; C. if (n < 0) { n = 0; } ? 18

Answer: C n If, later on, you want to add a statement, it’s easy to make this mistake with B: n n if (n < 0) System. out. println("n was " + n); n = 0; You won’t make this mistake with A or C n n With C (using braces), you don’t have to change anything that’s already there However, A (all on one line) is often convenient 19

Which is better? n Assume n is an integer: A. int factorial = 1; for (int i = 2; i < n; i++) { factorial *= n; } B. int factorial = 1; int i; for (i = 2; i < n; i++) { factorial *= n; } ? 20

Answer: A n In most cases, you don’t care about the index of a for loop outside the loop n n n You typically give it an initial value in the loop You typically already have its final value in some variable or by some simple computation If you don’t need a variable, you shouldn’t have that variable n It doesn’t help anything, and it might get in the way 21

Which is better? A. int search(int[] array, int target) { for (int i = 0; i < array. length; i++) { if (array[i] == target) return i; } return -1; } B. int search(int[] array, int target) throws Not. Found. Exception() { for (int i = 0; i < array. length; i++) { if (array[i] == target) return i; } return new Not. Found. Exception(); } ? 22

Answer: A n n Exceptions should be used for exceptional cases, not for normal program control In almost all cases, not finding something in an array search is one of the expected outcomes n Of course, there can be exceptions 23

Which is better? A. private void combinations(int n, int t) throws Invalid. Argument. Exception { if (t < 0 || t > n) { throw new Invalid. Argument. Exception(); . . . B. private void combinations(int n, int t) { assert t >= 0 && t <= n; . . . ? 24

Answer: B n The method is marked private, so you (the person writing this class) will be the only one using this method n n If you call it incorrectly, it’s most likely a bug, not just an unexpected external event, and should be fixed, not tested for Besides, using an assert statement is a lot less work 25

Which is better? A. class Line { public Point start; public Point end; public double length; . . . } B. class Line { public Point start; public Point end; public double length() {. . . }; . . . } ? 26

Answer: B n Two main reasons: n The DRY principle says: Don’t repeat yourself n n n The length variable makes the object vulnerable to inconsistent changes n n n The length variable is a subtle kind of repetition; its value is determined by the start and end points Whenever you have the same information represented in two places, you have the extra requirement to keep them consistent If some external agency changed only the start or the end point, the length variable would become incorrect The length method would continue to give correct results If efficiency is a critical issue, use setters and getters 27

Which is better? n You need to write a class which splits input lines into fields: A. class Split { public Split(Input. Stream. Reader reader) // constructor public void read. Next. Line() throws IOException {. . . } public int num. Fields() {. . . } public String get. Field(int field. Number) {. . . } } B. class Split { public Split(String line) {. . . } //constructor public int num. Fields() {. . . } public String get. Field() {. . . } } ? 28

Answer: B n The second Split class just splits lines; it isn’t concerned with where the lines come from n The first version can only split lines that come from an input stream, and is therefore less versatile 29

Conclusions n n There are various ways to do things One way may be better than another because: n n It’s easier to read and understand It’s more familiar—the way things are usually done It’s less error prone, or provides better error detection It’s more efficient n This is a good reason when the savings are dramatic enough to be noticeable 30

The End “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason -- including blind stupidity. ” -- W. A. Wulf “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. ” -- Donald Knuth 31