1 / 15

Writing Maintainab le code

Writing Maintainab le code. Dr. Susan McKeever DT228/3 GUI Programming. Code Maintainability. Naming standards Comments Indentation Spacing Alignment Refactoring Variety of techniques. UI Programming. Coding Standards. 80% of lifetime cost of s/w goes to maintenance

alder
Download Presentation

Writing Maintainab le code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Writing Maintainable code Dr. Susan McKeever DT228/3 GUI Programming

  2. Code Maintainability • Naming standards • Comments • Indentation • Spacing • Alignment • Refactoring • Variety of techniques

  3. UI Programming Coding Standards 80% of lifetime cost of s/w goes to maintenance Always assume someone else will need to maintain your code Make your code readable and well explained Use coding standards and comments “If you don’t use coding standards, you’re wasting your time writing software

  4. So far..? • What ‘techniques’ have we looked to support writing code that is easy to maintain?

  5. Reminder: Using coding conventions • Use the conventions • Variables mixed case starting with lower. E.g. acctBalance, line • Constant are all upper case e.g. COLOR_RED • Methods are verbs, mixed case starting with lower e.g. getBalance()

  6. Using coding conventions • Classes: Names should be in first letter of each word capitalised (called CamelCase). Try to use nouns because a class is normally representing something in the real world: class Customer • class CurrentAccount • Interfaces: Names should be in CamelCase. They tend to have a name that describes an operation that a class can do: interface Comparable • interface ColourManager

  7. Reminder: Header blocks • Always include a Header block of comments at the top of your program explaining • Author, date written, date modified, and a description of • What the code does • **************************************************************************** • * * • * Author: Audrey Clinton * • * * • * Created: 03/03/12 * • * Modified: 12/Mov/2012 * • * Modification1: to change all date foramts from dd/mm to dd/mmm • *etc * • ************************************************* **************

  8. Reminder: Comments • A comment needed for every method to explain it’s purpose • And for relevant lines of code • GOLDEN RULE • Always comment as if the code will be modified by someone else, without access to your guidance

  9. Reminder: Indentation, alignment and Spacing • Proper alignment/ indentation of code X intmyfunction(int a) { if ( a == 1 ) { printf("one"); return 1; // the cursor is in this line } return 0; } intmyfunction (int a) { if ( a == 1 ) { printf("one"); return 1; // the cursor is in this line } return 0; }

  10. Refactoring • Definition • "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior",. In order to improve the NON functional aspects of the code

  11. Refactoring • In plain English… • Reorganising your code to make your code clearer and cleaner and simpler - without changing the functionality IDEs such as Eclipse provide refactoring support

  12. Refactoring techniques used • More “abstraction” (i.e. hiding the implementation details/complexity) • Examples of this: • Encapsulation of attributes • Use getter and setter methods for attributes • Replacing conditional code with polymorphism • E.g. Using Shape (super) /Circle (sub) /Square (sub) – instead of “if/else”

  13. Refactoring techniques used • Improve names and location of code • Examples of this: • Move repeating code in a class into a method • E.g. Eclipse will identify and move • Change field or method name to a more meaningful name • Eclipse will find all occurrences • Push class up or down (i.e. to super/sub class)

  14. Refactoring techniques used • Break Code into smaller, logical pieces • Examples of this: • Avoid large unnecessarilycomplex classes • Extract class – moves part of class to a new class • Avoid large complex methods • Extract method

  15. Eclipse’s support for refactoring Spread across 3 categories.. • Changing the name and physical organization of code, including renaming fields, variables, classes, and interfaces, and moving packages and classes • Changing the code within a class, including turning local variables into class fields, turning selected code in a method into a separate method, and generating getter and setter methods for fields • Changing the logical organization of code at the class level, including turning anonymous classes into nested classes, turning nested classes into top-level classes, creating interfaces from concrete classes, and moving methods or fields from a class to a subclass or superclass

More Related