CLEANER CODEREFACTORING PRACTICE

REFACTORING PRACTICES: CLEANER CODE

TABLE OF CONTENTS

▸ Motivation

▸ What is CLEAN CODE?

▸ Refactoring Practices

▸ Practice Scope

▸ Practice1: NumberAnalysis.java

▸ Practice2: TicTacToe.java

▸ Lessons Learned

2

MOTIVATION

▸ For deeper understanding of OOP and java

▸ Curious about more advanced coding styles

I searched proper references and chose the book!

Clean CodeA Handbook of Agile Software Craftsmanship by Robert Cecil Martin

3REFACTORING PRACTICES: CLEANER CODE

WHAT IS CLEAN CODE? (1/2)

▸ What is defined as clean code differs from each individual but the base is shown below:

CLEAN CODE

straightforward

easy to read

easy to understand

easy to maintain

good performance

lower dependency

higher cohesiveness

meaningful name

…

easy to enhance

…

4REFACTORING PRACTICES: CLEANER CODE

WHAT IS CLEAN CODE? (2/2)

▸ Martin explains the concept of clean code in a simplemanner, just like how the code should be.

▸ Clean code starts from variable and method names that describes its function, each method having only one function. This way, even the most complex class can be easily read when put all together.

▸ Any code can be converted into clean code with a little bit of refactoring.

5REFACTORING PRACTICES: CLEANER CODE

REFACTORING PRACTICES

PRACTICE SCOPE

▸ Easily-read statements

▸ Intention-revealing naming that follows Java’s naming conventions

▸ Simple methods

▸ Single responsibility for each Class

▸ Revealing OO-concepts in codes

7REFACTORING PRACTICES: CLEANER CODE

PRACTICE 1ANALYSING NUMBERS

PRACTICE 1

ANALYSING NUMBERS

▸ Program Purpose: AP Computer Science homework intended to practice a wide array of Java concepts

▸ Requirements:

1. It should be written in the form of a console program.

2. Various kinds of operations should be provided.

3. Operation selection should be repetitive.

9

PRACTICE 1

ANALYSING NUMBERS

▸ Example of Program Execution

10

Input from keyboard

Operation choice

Operation choice

PRACTICE 1

CLASS DIAGRAM OF INITIAL CODE

11

A list of numbers to be calculated

An array for making histogram

An array for obtaining modulusDisplaying repetitive prompts

PRACTICE 1

MAIN() METHOD

Keep storing numbers from keyboard

until the value is zero

Make a choice anddisplay the result

PRACTICE 1

PROBLEMS (1/2)

13

Vague Naming

Method names not following Java naming convention

Wrong visibility

PRACTICE 1

PROBLEMS (2/2)

14

Hard to understand

Hard to read

Indistinct identifier

PRACTICE 1

REFACTORED

▸ Class Diagram

15

Class name, variables and methodsrenamed

Methods extracted

Visibility corrected

Constant added

PRACTICE 1

REFACTORED

▸ main() and public method run()

16

Test code with high readability by extracting a method and correcting visibility.

Now,fillNumberArray() and run() are visiblein main() method and run() uses the private methods inside.

PRACTICE 2TIC-TAC-TOE

PRACTICE 2

TIC-TAC-TOE

▸ Requirements

1. Display the game board and the respected crosses and noughts with symbols.

2. Game continues until a player wins or ties.

18

PRACTICE 2

TIC-TAC-TOE

▸ Example of Program Execution

19

Initial game board

Pick a row and column in turn

Game End

and display a board

PRACTICE 2

CLASS DIAGRAM OF INITIAL IMPLEMENTATION

20

A constructor initialising and print the game board

A method that checks to see if a player has won or tied

An array that contains the game board

PRACTICE 2

PROBLEMS (1/2)

21

Unclear variable name

Different functions containedin one method

Method namebreaking naming convention

PRACTICE 2

PROBLEMS (2/2)

22

Bug latent

I found the bug that already-chosen cell can be replaced in the refactoring process.

PRACTICE 2

CLASS DIAGRAM OF CODE REFACTORED

23

Constant variables created

The board and the parameters renamed Methods split so each has one function

Class dissection

PRACTICE 2

HOWEVER, I THOUGHT..

24

TicTacToe.java still seems heavy.

Local variables might not be necessary.

Ways to eliminate error-prone code?

Is the class dissection right?

…

PRACTICE 2

REFACTORING ONCE AGAIN

25

+ Three valid states

+ Clearer relations among classes

+ More understandable classes and its role

Now,

ü it became more understandable and maintainable structure.

ü I made reusable classes.

ü Unintentionally I fixed a bug.

LESSONS LEARNED (1/2)

▸ I had a chance to review bad code smells in my code.

▸ In the refactored code,

▸ methods and classes are much easier to read.

▸ the sub methods are easier to maintain.

▸ code becomes easier to read and understand without the need of comments.

▸ code becomes maintainable for future bugs and/or tweaks.

26REFACTORING PRACTICES: CLEANER CODE

LESSONS LEARNED (2/2)

▸ To keep coming back to the code and revise it makes better code.

▸ Refactoring can be those important and meaningful practice.

▸ Keep in mind “The Boy Scout Rule”

27REFACTORING PRACTICES: CLEANER CODE