• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Clean code lecture part I
 

Clean code lecture part I

on

  • 4,304 views

PT.BUZOO INDONESIA is No1 Japanese offshore development company in Indonesia. ...

PT.BUZOO INDONESIA is No1 Japanese offshore development company in Indonesia.
We are professional of web solution and smartphone apps. We can support Japanese, English and Indonesia.
We are hiring now at http://buzoo.co.id/

Statistics

Views

Total Views
4,304
Views on SlideShare
4,304
Embed Views
0

Actions

Likes
3
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Clean code lecture part I Clean code lecture part I Presentation Transcript

    • Introduction to Clean Code & Names part I By Niko Adrianus Yuwono
    • It is not the language that makes programs appear simple. It is the programmer that make the language appear simple
    •  Dave Thomas says code can be described as a clean code when : 1. The code is simple & direct. 2. Can be read, and enhanced by a developer other thank it’s original author. 3. It has meaningful names. 4. It provides one way rather than many ways for doing one thing. 5. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API.
    •  Code is the core of the application. Code represents the details of the requirement. Code is really the language in which we ultimately express the requirements.  If you’ve been in a team project you have probably been significantly slowed down by someone else’s messy code.
    •  Only knowing how to recognize clean code from dirty code is not enough because it’s doesn’t mean we know how to write clean code.  In this lecture we’ll do some exercises to help us to know how to write clean code and make it a habbit.
    •  Names are everywhere in software. We name our variables, our functions, our arguments, classes, and packages. We name our source files and the directories that contain them.  Because we do so much of it, we’d better do it well. What follows are some simple rules for creating good names.
    •  The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent. int e; // total number of employee
    •  The name e reveals nothing. We should choose a name that specifies what is being measured and the unit of that measurement:  Another example int totalNumberOfEmployee; int daysSinceLastLogin; String employeeEmailAddress
    •  This is an example of dirty code public ArrayList<int[]> getThem() { ArrayList<int[]> ArrayList1 = new ArrayList<int[]>(); for (int[] x : globalArrayList) if (x[0] == 4) ArrayList1.add(x); return ArrayList1; }
    •  Why is it a dirty code? Because we cannot comprehend what’s the author want to express in his code. The code is very implicit. We must ask the author some question like : 1. What kinds of things are in globalArrayList? 2. What is the significance of the 0th subscript of an item in globalArrayList? 3. What is the significance of the value 4? 4. How would I use the list being returned?
    •  We can rewrite the dirty code to this one: public ArrayList<Member> getDietitianMember() { ArrayList<Member> dietitianMembersList = new ArrayList<Member>(); for (Member member : allMemberList) if (member[TYPE] == DIETITIAN) dietitianMembersList.add(member); return dietitianMembersList; }
    • public ArrayList<Member> getDietitianMember() { ArrayList<Member> dietitianMembersList = new ArrayList<Member>(); for (Member member : allMemberList) if (member.isDietitian()) dietitianMembersList.add(x); return dietitianMembersList; }
    •  We should avoid words whose entrenched meanings vary from our intended meaning.  For example do not refer to a grouping of accounts as an accountList unless it’s actually a List.  Beware of using names which vary in small ways. How long does it take to spot the subtle difference between a XYZControllerForEfficientHandlingOfStrings in one module and, somewhere a little more distant, XYZControllerForEfficientStorageOfStrings?
    •  Usually when we can’t use the same name to refer to two different things in the same scope, we might be tempted to change one name in an bad way like a1 and a2.  It is not sufficient to add number series, even though the compiler is satisfied. If names must be different, then they should also mean something different.
    •  This function is an example of a noninformative function  The use of variable a1 and a2 didn’t give us clue what is the author intention. public static void copyChars(char a1[], char a2[]) { for (int i = 0; i < a1.length; i++) { a2[i] = a1[i]; } }
    •  Some other example of indistinguishable name : 1. money and moneyAmount 2. customer and customerInfo 3. accountData and account 4. theMessage and message