Clean code
Upcoming SlideShare
Loading in...5
×
 

Clean code

on

  • 1,980 views

 

Statistics

Views

Total Views
1,980
Views on SlideShare
1,964
Embed Views
16

Actions

Likes
2
Downloads
36
Comments
0

2 Embeds 16

http://www.slideshare.net 15
http://www.scoop.it 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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 Clean code Presentation Transcript

    • CLEAN CODE By: Sharevison Team 8º Simpósio Brasileiro de Linguagens de Programação
    • How do you know, how bad your code is?
    • Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and per- formance close to optimal so as not to tempt people to make the code messy with unprinci-pled optimizations. Clean code does one thing well.
    • “Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal depen dencies, which are explicitly defined, and pro- vides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.
    • Michael Feathers, author of Working Effectively with Legacy Code I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by some one who cares deeply about the craft.
    • My personal View The code considered to be clean will need these: Well written test (Unit test) for every public methods. A class should be small and does one thing only A method should be small enough( not longer then 20 lines) A method should does only one thing and does it well After all, I should able to hand over my code to other, and they should able to carry on the work.
    • Productivity vs. Time
    • Meaningfull Names Use Intention-Revealing Names: Intention- It should tell you why it exists, what it does, and how it is used. int d; // elapsed time in days OR int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;
    • Avoid Disinformation avoid words whose entrenched meanings vary from our intended meaning. Eg. grouping of accounts -> var accountList
    • Use Pronounceable Names class DtaRcrd102 { private Date genymdhms; private Date modymdhms; private final String pszqint = "102"; /* ... */ }; To class Customer { private Date generationTimestamp; private Date modificationTimestamp;; private final String recordId = "102"; /* ... */ };
    • Avoid Encodings Hungarian Notation PhoneNumber phoneString; // name not changed when type changed! Member Prefixes public class Part { private String m_dsc; // The textual description void setName(String name) { m_dsc = name; } } To public class Part { String description; void setDescription(String description) { this.description = description; } }
    • Avoid Mental Mapping Readers shouldn’t have to mentally translate your names into other names they already know. This problem generally arises from a choice to use neither problem domain terms nor solution domain terms. var r; //url var fn; //first name
    • Method Method should be a verbphrase like getAccount, displayTest ...etc.
    • Don’t Be Cute What about this HolyHandGrenade or DeleteItems
    • Pick One Word per Concept Pick one word for one abstract concept and stick with it Eg. Fetch(), retrieve(), get() as equivalent methods of different classes. controller and a manager and a driver in the same code base.
    • Don’t Pun Avoid using the same word for two purposes Eg. add(firstItem, secondItem), concatinat two items. add(newItem), append to existing item
    • Use Solution Domain Names Do not afraid of using computer science team like: Name of patters Algorithm • getMinWidthComposite() •AccountVisitor
    • Add Meaningful Context enclosing them in well-named classes, functions, or namespaces private void thereIsOneLetter() { number = "1"; verb = "is"; pluralModifier = ""; }
    • Function Small, should be hardly every 20 lines long Does one thing, it should does one thing, does it well, and does it only.
    • Function: One Level of Abstraction per Function gtk.Button.prototype.setImage = function(image){ this._widget2 = image; this.resize(this._minWidth, this._minHeight); this._widget2._domObj.style.display = ""; this._imageDom.appendChild(this._widget2._domObj); }; To gtk.Button.prototype.setImage = function(image){ this._widget2 = image; this.resize(this._minWidth, this._minHeight); this.hide(this._widget2); this._appendImage(this._widget2._domObj); }; gtk.Button.prototype.hideWidget = function(widget){ widget._domObj.style.display = ""; }; gtk.Button.prototype.appendImage = function(){ this._imageDom.appendChild(this._widget2._domObj); };
    • Function Arguments What is the best number of arugments passed in: Zero (niladic) Two (dyadic) Three (polyadic) More then this is evil Reasons not to have many arguments: For public methods, user fine it hard to use the method. For private method, it should able to access the class properties, why have to pass in.
    • Function Arguments Flag Arguments: Passing a boolean into a function is a truly terrible practice render(true) OR renderForSuite() and renderForSingleTest()
    • Function Arguments Argument Objects: more than two or three arguments, they ought to be wrapped into a class of their own. Circle makeCircle(double x, double y, double radius); OR Circle(circleProperties);
    • Don’t repeat yourself If you see the same code structure more than one place, then extract the method and invoke the code from both places
    • Switch Statement How to make switch statement does one thing? public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } }
    • Comment Comments Do Not Make Up for Bad Code: “Ooh, I’d better comment that!” No! You’d better clean it!” // Check to see if the employee is eligible for full benefits if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) OR if (employee.isEligibleForFullBenefits())
    • Good Comments
    • Comment Legal Comments // Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved. // Released under terms of the GNU General Public License version 2 or later. Informative Comments // Returns an instance of the Responder being tested. protected abstract Responder responderInstance(); OR protected abstract Responder getResponderInstance();
    • Warning of Consequences Warning of Consequences // Don't run unless you // have some time to kill. public void _testWithReallyBigFile() { writeLinesToFile(10000000); response.setBody(testFile); response.readyToSend(this); String responseString = output.toString(); assertSubString("Content-Length: 1000000000", responseString); assertTrue(bytesSent > 1000000000); }
    • TODO Comments Leave TODO comment //TODO-MdM these are not needed // We expect this to go away when we do the checkout model protected VersionInfo makeVersion() throws Exception { return null; }
    • Bad Comments
    • Redundant Comments The comment that takes longer to read than the code itself // Utility method that returns when this.closed is true. Throws an exception // if the timeout is reached. public synchronized void waitForClose(final long timeoutMillis) throws Exception { if(!closed) { wait(timeoutMillis); if(!closed) throw new Exception("MockResponseSender could not be closed"); } }
    • Noise Comments Sometimes you see comments that are nothing but noise. They restate the obvious and provide no new information. /** * Returns the day of the month. * * @return the day of the month. */ public int getDayOfMonth() { return dayOfMonth; }
    • Don’t Use a Comment When You Can Use a Function or a Variable // does the module from the global list <mod> depend on the // subsystem we are part of? if (smodule.getDependSubsystems().contains(subSysMod.getSubSystem())) OR ArrayList moduleDependees = smodule.getDependSubsystems(); String ourSubSystem = subSysMod.getSubSystem(); if (moduleDependees.contains(ourSubSystem))
    • Position Markers Mark a particular position in a source file // Actions //////////////////////////////////
    • Class Names Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser.
    • Reference Clean Code: a hand book of agile software craftmanship by Robert C. Martin Refactoring, Improving the design of existing code by Martin Fowler