Java

Choose one of the exercises you did in this session and re-write your code using the tips and standards given to you in the handout on refactoring.

public class Triangle { public Triangle(double s1, double s2, double s3) { }

public static void main(String[] args) { java.util.Scanner in = new java.util.Scanner(System.in); System.out.print("Please enter the 3 sides of your triangle: "); double s1 = in.nextDouble(); double s2 = in.nextDouble(); double s3 = in.nextDouble(); System.out.print("Please enter the color: "); String color = in.next(); System.out.print("Is the triangle filled (true or false): "); boolean filled = in.nextBoolean(); Triangle t = new Triangle(s1, s2, s3); t.setColor(color); t.setFilled(filled); System.out.printf("Triangle perimeter: %.2f%n" + "Triangle area: %.2f%n" + "Triangle color: %s%n" + "Triangle filled? %s%n", t.getPerimeter(), t.getArea(), t.getColor(), t.isFilled()); }

private Object isFilled() { return null; }

private Object getColor() { return null; } private Object getArea() { return null; }

private Object getPerimeter() { return null; }

private void setFilled(boolean filled) { }

private void setColor(String color) { }

}

Reractoring In the beginning there was old-style programming.... Since it was a new science/art it was sort of like the Wild West: People did as they pleased. There weren't a lot of rules Programming was considered linear, which basically meant you started at the beginning and kept writing code until the end, then fixed it until it worked. I remember this era. Variables were usually short like: x, y and z (less typing). Reuse of code meant you copied and pasted the source from another source and then fiddled with it until it worked. Sometimes you didn't really understand exactly what the code that you cut and pasted did, so there may be more functionality than you used. Methods /functions were created and re-created again when you needed them in a different place. In many companies there weren't standards for programmers to follow and weren't code reviews. So once you fixed a program you simply turned it in...with no one else checking it. Programmers didn't really learn from each other (which is the other function of code reviews). Code routines were long and poorly documented. Logic was convoluted. ...And much of this code is still around today! Much of that is 'patched to modify it to work in today's environment. Chances are that in the.course of your programming work, you will be asked to fix someone else's code. The less clear the comments, the harder it will be to fix. The longer the methods and classes the harder it is to maintain legacy code. The more cryptic the variable names, the harder it is to understand. You will also see that if you fix a problem in one place, you will fix it in other places. So errors keep reoccurring in different sections of code. The more convoluted the logic, the harder it is to fix-without introducing more errors. The longer and more 'catch-all' the purpose of a section of code, the harder it is to test. Recently I talked to a senior programmer at a defense contractor. He is one of the most valued programmers in his company. He spends a large amount of his time refactoring code. Basically that means he redesigns legacy code to make it easier to maintain and easier to use and reuse. (How does this save his company money? Is he well paid for his expertise?) He also said he's been ignoring a problematic section of code, 3000 lines of messy code in one class, because he doesn't have the time to fix it (Refactoring is a term introduced in context with Agile Programming. For more information search for Agile Programming and refactoring) Refactoring is not rocket science, but is like good puzzle solving. There is automated software to help you refactor, but many times you will be asked to refactor code by hand. Many more times you will be asked to fix a problem, and along the way find it easier or better to refactor the code. Understanding refactoring also helps you understand good coding standards. Note: Many sources recommend that when you find code that should be refactored, but don't have the time, you mark the sections with //TODO or //FIX THIS