Scribd Logo
Upload

Welcome to Scribd!

  • 32 views

    Clean Code

    Uploaded by

    Rajesh Jangra
    This document discusses principles and best practices for writing clean code, including: 1. Code should have meaningful names, avoid ambiguous names, and use searchable variable names. 2. Magic numbers should be avoided and replaced with named constants. Methods should have a single responsibility, use verbs in names, and avoid flag arguments. 3. Comments should be avoided when possible by writing clear, intention-revealing code. Formatting and structure are also important for readability. 4. Error handling should use exceptions rather than return codes, and tests should follow the FIRST principles with one assert per test. Classes and modules should have a single responsibility.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    Clean Code

    Uploaded by

    Rajesh Jangra
    32 views21 pages
    This document discusses principles and best practices for writing clean code, including: 1. Code should have meaningful names, avoid ambiguous names, and use searchable variable names. 2. Magic numbers should be avoided and replaced with named constants. Methods should have a single responsibility, use verbs in names, and avoid flag arguments. 3. Comments should be avoided when possible by writing clear, intention-revealing code. Formatting and structure are also important for readability. 4. Error handling should use exceptions rather than return codes, and tests should follow the FIRST principles with one assert per test. Classes and modules should have a single responsibility.

    Original Title

    Clean Code.pptx

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses principles and best practices for writing clean code, including: 1. Code should have meaningful names, avoid ambiguous names, and use searchable variable names. 2. Magic numbers should be avoided and replaced with named constants. Methods should have a single responsibility, use verbs in names, and avoid flag arguments. 3. Comments should be avoided when possible by writing clear, intention-revealing code. Formatting and structure are also important for readability. 4. Error handling should use exceptions rather than return codes, and tests should follow the FIRST principles with one assert per test. Classes and modules should have a single responsibility.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    32 views21 pages

    Clean Code

    Uploaded by

    Rajesh Jangra
    This document discusses principles and best practices for writing clean code, including: 1. Code should have meaningful names, avoid ambiguous names, and use searchable variable names. 2. Magic numbers should be avoided and replaced with named constants. Methods should have a single responsibility, use verbs in names, and avoid flag arguments. 3. Comments should be avoided when possible by writing clear, intention-revealing code. Formatting and structure are also important for readability. 4. Error handling should use exceptions rather than return codes, and tests should follow the FIRST principles with one assert per test. Classes and modules should have a single responsibility.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    You are on page 1of 21

    CLEAN CODE

    RAJESH KUMAR

    1
    WHAT IS CLEAN CODE

     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 is complete,
     Clean code does one thing well.
    Bjarne Stroustrup

    2
    MEANINGFUL NAMES

     int i;
     What is i?
     int elapsedTime;
     Now we know it is an integer indicating elapsed time.
     But what time? Seconds, years what?
     int elapsedTimeInDays
     Better?
     int elapsedTimeInDaysSinceRestart
    3
    MEANINGFUL NAMES

     controllerForEfficientHandlingOfStrings
     controllerForEfficientStorageOfStrings
     Frightfully similar
     int a = l;
       if ( O == 0 ){
         a = O;
    }
     Not very clear?
    4
    MEANINGFUL NAMES

     Names with similar meaning


     accountData vs account
     customerInfo vs customer
     Variable names should be pronounceable
     dtValFmtddmmyy
     dateValueFormattedAsddmmyy
     Use searchable names
     If you must search a variable named “a”

    5
    NO MAGIC NUMBERS

    public List<int[]> getList(List<int[]> inputList) {


    List<int[]> tempList = new ArrayList<>();
    for (int[] x : inputList)
    if (x[0] == 4) tempList.add(x);
    return tempList;
    }

    6
    NO MAGIC NUMBERS CONTD

    public List<int[]> getFlaggedCells(List<int[]> gameBoard) {


    List<int[]> flaggedCells = new ArrayList<>();
    for (int[] cell : gameBoard)
    if (cell[STATUS_VALUE] == FLAGGED)
    flaggedCells.add(cell);
    return flaggedCells;
    }

    7
    METHODS

     Method name must be verb


     One name per concept
     Fetch, retrieve, get
     Do not add too much context
     E.g. Prefixing everything with application name
     Must always return value
     Should not have side effects
    8
    METHODS CONTD

     Keep methods small


     And make sure it does one thing
     Niladic, monadic and dyadic
     Triadic is so evil, try enclosing in a class if really required
     So are flag arguments, It means method does more than one thing

    9
    FUNCTIONS CONTD

     Command query separation


     Method should do something or answer something but not both
     Prefer exceptions to returning error codes
     Violate the command query separation
     The error codes class is dependency magnet

    10
    WORDS OF WISDOM

     Every function, and every block within a function, should have one entry
    and one exit.
     Means that there should only be one return statement in a function,
     no break or continue statements in a loop,
     and never, ever, any goto statements.
     Dijkstra

    11
    COMMENTS

     What would you prefer?


    // Check if employee is eligible for full benefits
    if (employee.flag && employee.age > 65)
     Or
    if (employee.isEligibleForFullBenefits())

    12
    COMMENTS

     Do not comment bad code, rewrite it, refactor it


     Kernighan
     If your code can not reveal its intention, then the comments shall neither.
     The comments are seldom maintained
     Comments clutter the code
     TODO comments

    13
    FORMATTING

     Is as important as the code itself


     Should be standardized for a project
     The old Hollerith limit of 80 is a bit old and most screens allow width greater than
    that

    14
    ABSTRACTION

     Do not blindly create getters and setters


     Understand when to use
     Procedural
     Object oriented
     DTOs do nothing more than to duplicate code

    15
    ERROR HANDLING

     Use informative error messages


     Do not catch and re-throw
     Use exceptions rather than error codes
     Write try-catch-finally in separate function?
     Checked vs Unchecked exceptions?
     Violates open closed principle

    16
    TESTS

     F.I.R.S.T. principle
     Tests must be uniquely named
     Given-When-Then
     One assert per test
     Making a private function protected to test
     Generally, not required if the functions are small

    17
    CLASSES

     Single Responsibility Principle


     Too many classes
     Look for cohesion
     Dependency Inversion Principle
     Enums vs constants
     Do not inherit constants

    18
    SYSTEM

     Object creation should be separated from business logic


     Dependency Injection, Factories
     Cross cutting concerns
     Business logic should be separate from framework related code

    19
    SYSTEM

     Always delete commented code


     And dead code i.e unreachable code
     Building and deploying a system should be one step
     Should be able to run all tests on local
     Do not override safeties
     Maintain separation between layers

    20
    QUESTIONS?

    21

    You might also like