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.

import java.util.ArrayList; import java.util.Scanner; public class SortArray { public static void sort(ArrayList list) { Integer temp; for(int i = 0; i 0) { temp = list.get(j); list.set(j, list.get(j+1)); list.set(j+1, temp); } } } } public static void main(String[] args) { Scanner in = new Scanner(System.in); ArrayList list = new ArrayList(); System.out.println("Enter 5 numbers: "); for(int i = 0; i out.println("Normal list: " + list.toString()); sort(list); System.out.println("Sorted list: " + list.toString()); } }

Refactoring Good code standards: 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 vou 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 * No classes over 1000 lines (breakup large classes and extract superclasses .No methods over 50 lines (breakup long methods and extract methods) No duplicate code Meaningful comments .Meaningful method names (findRecordByld O is clearer than findMe10) .Meaningful variable names, not misleading, cryptic or cute No repeating variable names inside and outside methods .No complex conditional logic. Use Polymorphism instead of conditionals where Clear purpose of each class and method (no dual purposes) Clear logic of each class and method . e Therefore you can usually identify code suitable for refactoring by identifying code that violates many or most of these standards. The extent to which you refactor the code is really determined by the time available and how problematic the code is as-is. 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 wll fix it in other places. So errors keep reoccuring 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. Where to begin? I prefer to start with method names and variable names, move to breaking up classes and methods (and through this eliminate duplicate code), and finish with the elimination of the conditionals as appropriate by replacement with polymorphism. 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 compary 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 orFIX THIS