This site is from a past semester! The current version will be here when the new semester starts.
CS2103/T 2020 Aug-Dec
  • Full Timeline
  • Week 1 [Mon, Aug 10th]
  • Week 2 [Fri, Aug 14th]
  • Week 3 [Fri, Aug 21st]
  • Week 4 [Fri, Aug 28th]
  • Week 5 [Fri, Sep 4th]
  • Week 6 [Fri, Sep 11th]
  • Week 7 [Fri, Sep 18th]
  • Week 8 [Fri, Oct 2nd]
  • Week 9 [Fri, Oct 9th]
  • Week 10 [Fri, Oct 16th]
  • Week 11 [Fri, Oct 23rd]
  • Week 12 [Fri, Oct 30th]
  • Week 13 [Fri, Nov 6th]
  • Textbook
  • Admin Info
  • Dashboards
  •  Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Showcase
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Addressbook-level3
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Tutorial Schedule
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard
  • Module OverviewModule Expectations


    Using this Website

    The Schedule page is your main source of information for CS2103/T. You will need to refer to it weekly. For an overview of the full schedule, refer to the Full Timeline page.

    More details for the upcoming weeks will be added as the weeks progress. In general, information given for more than 1 week into the future should be treated as tentative.

    Browser compatibility

    Most of this will work on most mainstream Browsers, but embedded slides are best viewed using Chrome.

    Information layers

    This book tries to layer information so that readers can decide to omit less important layers if they wish to.

    More important information are in bold or highlighted while less important information are dimmed or in collapsed panels such as the below.

    Less important info

    Less important info

    Less important info

    Tabs indicate alternative formats of the same content (e.g. video vs text). You can choose the one you like and ignore the other tabs.

    Some textual description of X

    Video describing X

    Dotted underlines indicate some additional infotool tips (activated by hovering over it) and dashed underlines indicate modal windows (activated by clicking) containing additional information.

    Tooltip Example
    Additional information
    Additional information

    This website uses a star rating system to indicate the priority level of contents.

    Star Rating System

    We use a star rating system to indicate the importance of module components. Start with things that are rated one-star and progress to things with more stars. Things rated four stars are optional.

    Star ratings for topics (and textbook sections):

    • One-star topics are essential to keep up with the module. We recommend you to learn these topics if you want to pass the module (i.e. up to a C grade).
    • Two-stars topics can get you up to a B+.
    • Three-stars topics can get you up to an A.
    • Four-stars topics : OPTIONAL can push you beyond the limits of the module, and help you get into a level above those who merely limit themselves to the topics of the module. They are not examinable here means can affect the grade during evaluation of various components, not necessarily limited to the final exam (if any)examinable.
    • Topics marked with two icons e.g., : , : , : are relevant topics you are expected to have learned in prerequisite modules. They are given for reference, but are examinable. The number of stars indicates the progression of topics, similar to the star rating system above i.e., one-star prerequisite topics are the most basic and the most important. four-star pre-requisite topics can be ignored without affecting CAP.

    Star ratings for other things e.g., admin info sections:

    • The module uses a similar star rating system to indicate the importance of other info in this website. i.e., information rated as one-star are the most essential. Info rated four stars are non-essential and can be ignored without affecting your ability to follow the module.

    Conventions used

    Shorthand headings

    Meaning of some shortened headings:

    • What : the meaning of the concept in concern (example)

    Implementation → Refactoring →

    What

    The first version of the code you write may not be of production quality. It is OK to first concentrate on making the code work, rather than worry over the quality of the code, as long as you improve the quality later. This process of improving a program's internal structure in small steps without modifying its external behavior is called refactoring.

    • Refactoring is not rewriting: Discarding poorly-written code entirely and re-writing it from scratch is not refactoring because refactoring needs to be done in small steps.
    • Refactoring is not bug fixing: By definition, refactoring is different from bug fixing or any other modifications that alter the external behavior (e.g. adding a feature) of the component in concern.

    Improving code structure can have many secondary benefits: e.g.

    • hidden bugs become easier to spot
    • improve performance (sometimes, simpler code runs faster than complex code because simpler code is easier for the compiler to optimize).

    Given below are two common refactorings (more).

    Refactoring Name: Consolidate Duplicate Conditional Fragments

    Situation: The same fragment of code is in all branches of a conditional expression.

    Method: Move it outside of the expression.

    Example:

    if (isSpecialDeal()) {
    total = price * 0.95;
    send();
    } else {
    total = price * 0.98;
    send();
    }
     → 
    if (isSpecialDeal()) {
    total = price * 0.95;
    } else {
    total = price * 0.98;
    }
    send();

    if is_special_deal:
    total = price * 0.95
    send()
    else:
    total = price * 0.98
    send()
     → 
    if is_special_deal:
    total = price * 0.95
    else:
    total = price * 0.98

    send()

    Refactoring Name: Extract Method

    Situation: You have a code fragment that can be grouped together.

    Method: Turn the fragment into a method whose name explains the purpose of the method.

    Example:

    void printOwing() {
    printBanner();

    // print details
    System.out.println("name: " + name);
    System.out.println("amount " + getOutstanding());
    }

    void printOwing() {
    printBanner();
    printDetails(getOutstanding());
    }

    void printDetails(double outstanding) {
    System.out.println("name: " + name);
    System.out.println("amount " + outstanding);
    }
    def print_owing():
    print_banner()

    # print details
    print("name: " + name)
    print("amount " + get_outstanding())

    def print_owing():
    print_banner()
    print_details(get_outstanding())

    def print_details(amount):
    print("name: " + name)
    print("amount " + amount)

    Some IDEs have builtin support for basic refactorings such as automatically renaming a variable/method/class in all places it has been used.

    Refactoring, even if done with the aid of an IDE, may still result in regressions. Therefore, each small refactoring should be followed by regression testing.

    Choose the correct statements.

    • a. Refactoring can improve understandability
    • b. Refactoring can uncover bugs
    • c. Refactoring can result in better performance
    • d. Refactoring can change the number of methods/classes

    a, b, c, d

    Explanation:

    • (a, b, c) Although the primary aim of refactoring is to improve the internal code structure, there are other secondary benefits.
    • (d) Some refactorings result in adding/removing methods/classes.

    Do you agree with the following statement? Justify your answer.

    Statement: Whenever you refactor code to fix bugs, you need not do regression testing if the bug fix was minor.

    There are two flaws in the given statement.

    DISAGREE.

    1. Even a minor change can have major repercussions on the system. You MUST do regression testing after each change, no matter how minor it is.
    2. Fixing bugs is technically not refactoring.

    Explain what refactoring is and why it is not the same as rewriting, bug fixing, or adding features.

    • Why : the motivation behind the concept in concern (example)

    Implementation → Documentation → Guidelines → Describe Top-Down →

    Why

    The main advantage of the top-down approach is that the document is structured like an upside down tree (root at the top) and the reader can travel down a path she is interested in until she reaches the component she is interested to learn in-depth, without having to read the entire document or understand the whole system.

    • How : the usage of the concept in concern (example)

    Implementation → Refactoring →

    How

    Given below are some more commonly used refactorings. A more comprehensive list is available at refactoring-catalog.

    1. Consolidate Conditional Expression
    2. Decompose Conditional
    3. Inline Method
    4. Remove Double Negative
    5. Replace Magic Literal
    6. Replace Nested Conditional with Guard Clauses
    7. Replace Parameter with Explicit Methods
    8. Reverse Conditional
    9. Split Loop
    10. Split Temporary Variable
    • When : the pros and cons of the concept in concern, when to use the concept (example)

    Implementation → Refactoring →

    When

    You know that it is important to refactor frequently so as to avoid the accumulation of ‘messy’ code which might get out of control. But how much refactoring is too much refactoring? It is too much refactoring when the benefits no longer justify the cost. The costs and the benefits depend on the context. That is why some refactorings are ‘opposites’ of each other (e.g. extract method vs inline method).

    ‘Extract method’ and ‘Inline method’ refactorings

    a

    Meaning of icons

    : additional info
    : warning
    : positive message
    or : important message
    : error or danger to avoid
    or : tip
    : definition or topic
    extra : tangential info, can be ignored if not interested
    : Ctrl+Click to open the LO in new window/tab.
    : learning outcomes
    : prerequisite learning outcome
    : examples
    : resources
    : exercises
    : printable version
    : preview/more info
    : video
    >_ : a command to be run in a terminal
    : textual description
    : slides
    : output produced by running code
    question without answer
    question with answer

    : tasks to do
    : lecture
    : tutorial
    : evidence you can use to prove you have achieved a learning outcome
    ⏰ : deadline

    Searching for keywords

    Use the search box in the top navigation bar to search for keywords in the website pages. If you cannot find the content related to a keyword, let us know by posting in the forum so that we can add the missing keyword to our search index.

    Saving as PDF files

    Follow this guide @SE-EDU/guides.

    Printing Textbook Content

    Printer-friendly version (indicated by icon) have been provided for each chapter and the whole book. You can use them for saving as pdf files or printing.

    Making this Website Better

    This website was generated using the MarkBind software developed at NUS. We welcome bug reports, suggestions, and contributions, to be submitted at the website issue tracker.


    Module OverviewModule Expectations