Advanced Programming: Tools and Techniques

Advanced Programming: Tools and Techniques in which we aim to introduce potentially useful techniques and related tools to assist the process of turning hackers into programmers into software engineers

1.

Language, Style and Practice

– “Coding for humans”

2.

Source Code Management

– Revision control and make

3.

A Practical Introduction to CVS

– Using the CVS revision control system

4.

Compilers and Libraries

– What they do, why I should care

5.

Analysis, Debugging and Profiling

– The art of programming

Course overview

2 Advanced Programming: Tools and Techniques - Session 1

1

3


Rob Baxter , Project Manager

Advanced Programming: Tools and Techniques - Session 1


4 Computer languages

– Pros and cons

– Which to use?

4 Programming style

– Why it’s important

– Coding for readability, comprehensibility, maintainability

– Variable naming and comments

– Organising source code

4 Tools for beautifying and formatting


2

Computer languages

4 What is the best programming language to learn ?

4 This is, of course, a meaningless question

4 There are many different programming languages because there are many different problems

4 A programming language is simply a tool

– Choosing which tool depends on the problem

– Can be a difficult thing to do, and repercussions can be great

4 Language choice should be driven by application requirements, not vice versa


Some examples...

4 Scientific/engineering simulation applications

– High performance; good libraries; parallelism

4 Complex datastructures important to algorithm

– Database records; linked lists; hash tables

4 Naturally data- or object-oriented design

– Graphics codes; database applications; event-driven

4 GUI application

– User interfaces; database front-ends; Web applications

4 Complex I/O processing needed

– Text processing; scientific pre/post processing

4 System integration

– Low-level device drivers; O/S interaction; heterogeneity


3

Fortran - pros

4 Simplicity of available datastructures reduces bug potential

– No pernicious pointers or dangerous memory leaks...

4 Venerable compilers

– Well optimised, especially on HPC

– Still has performance edge

4 Maps well to mathematics

– Intrinsic complex type

– Fortran 90 array syntax

– Still good first choice language for science

4 Widely spoken by scientists and engineers


Fortran - cons

4 Simplicity of available datastructures can make for difficult code

– Stacks? Linked lists? Well, you can...

– Makes data-oriented design harder

4 I/O features rather archaic

– Record-based

– Not best choice for text processing applications

4 Not widely spoken by many people other than scientists and engineers


4

C - pros

4 Pointers and dynamic memory

– Can manage memory more efficiently

– (although Fortran 90 has similar)

4 Richness of possible datastructures

– High-level data-oriented design easier to map to C

4 Powerful I/O features

– Excellent for text processing

4 Compilers are good, stable and well-optimised

4 Powerful standard preprocessor

4 Spoken widely


C - cons

4 Pointers and dynamic memory

– Memory leaks, dangling pointers, bug city...

4 Writing obscure code is quite easy

– a = b & c ? d : e;

– n[i] *= *m++ - k*l & i++ + ++p->j++;

– This is just rubbish...

4 Preprocessor macro language easy to abuse

– Undebuggable four-page macros


5

C++ - pros

4 Class structure

– Data-oriented design maps naturally to C++

– Data encapsulation presents clean interfaces to the world

4 Multiple inheritance

– Classes can inherit features from many parent classes

– Reusability thereby enhanced

4 Operator overloading

– Can transliterate complex mathematics directly

• a = b + c instead of a = b.add(c)

4 Large collection of class libraries

– Many useful classes for many different tasks


C++ - cons

4 Obscure syntax

– Some dreadfully hacky features...

– Can be difficult to learn, even for C programmers

4 Multiple inheritance

– Misuse generates non-understandable code

4 Operator overloading

– Ditto

4 Writing low-performance code quite easy

– Object instantiation overheads; late binding etc.

4 Limited portability of some class libraries

– “Sorry, we don't have a Unix version of that...”


6

Java - pros

4 Elegant class structure

– Data-oriented design maps naturally to Java

– Data encapsulation presents clean interfaces to the world

– Arguably cleaner than C++

4 No multiple inheritance or operator overloading

– Avoids some nasties available only in C++

4 Portability of compiled code

– Universal deployability

– Platform neutrality great for Web, system integration etc.

4 Window-based graphics as standard

– Simple graphics and visualisations instantly available


Java - cons

4 Semi-interpreted language

– Runs in a software “virtual” machine, not a real one

– Performance cannot compete with compiled languages

– Although JIT compilers improving all the time

4 Very object-oriented

– Doesn’t always map well to “procedural” problems

4 Syntax can be obscure

– try { n = Integer.parseInt(arg.substring(4, 3))

} catch(NumberFormatException e);


7

4 Flexible, free and easy

– A “get the job done” language

4 Powerful I/O and text processing features

– Excellent pre/post processing language

4 Powerful interaction with OS

– Good integration and control language

4 Class structure

– Again good for data-oriented design

Perl - pros


Perl - cons

4 Flexible, free and easy

– Easy to write non-robust code

4 Obscure syntax

– Some Perl constructs can be pretty mysterious:

$_ = <> until ($mode,$file) = /^#\s*(\d+)\s*(\S*)/;

(although there is use English;)

4 Semi-interpreted language

– Not a language of choice for high-performance simulation


8

Some examples...

4 Scientific/engineering simulation applications

– Fortran, C

4 Complex datastructures important to algorithm

– C, C++, Java

4 Naturally data or object-oriented design

– C++, Java

4 GUI application

– Java

4 Complex I/O processing needed

– C, Perl

4 System integration

– Java, Perl, C


Many others

4 Cobol, Pascal, Visual Basic, Lisp, ADA,

Smalltalk, Delphi, Tcl, Python, Unix shells...

4 Knowing several languages is a good thing

– Provides a wider selection of tools from which to choose

– Frees design from considerations of language

– Improves understanding of the concept of programming


9

Programming style

4 Coding style is not just design fascism

4 Here’s why...


Coding style guidelines

4 Every organisation should have these

4 Should be guidelines , not rigid and overprescriptive

– “All for loops in C must place the opening brace on the line after the for statement”

– Unnecessary and potentially slows developers

4 Aim should be to promote

– Readability

– Comprehensibilty

– Maintainability


10

“Coding for humans”

4 Code has to be understood two ways

– By the compiler

– By Joe the new grad student who suddenly has to maintain it

4 Compilers don’t care what code looks like as long as it’s correct

4 But, compilers don’t have to fix bugs four months down the line

4 Always write code you would be happy to have to read yourself


Self-documentation

4 All code should be documented on paper

– Design, implementation, user guides

4 Making code self-documenting is half the battle

– Even tools to generate paper documentation from wellformatted code: javadoc, doxygen, doc++

4 Things to take care of

– Layout and formatting

– Variable and function naming

– Avoiding obscure language constructs

– Comments!


11

Code documenters

4 javadoc

– Parses declarations and documentation comments in Java source

– Writes HTML pages describing classes, methods etc.

– Understands special “documentation comments” /**

– Available with standard JDK environments

4 doxygen

– Similar, for C/C++, Java and IDL

– Uses same /** documentation comments

– Also writes LaTeX, RTF, PDF as well as HTML

– Available from http://www.stack.nl/~dimitri/doxygen/


Layout and formatting

4 There is no “right” way to format code, but there are plenty of wrong ways!

4 Aim should be twofold

– To make code easier on the eye

– To emphasise the logical structure of the program

4 Key things to watch are

– Consistent indentation scheme for loops etc.

– Use of whitespace within expressions to separate variables, functions and operators

– Use of parentheses in expressions

– Blank lines to group logical algorithmic blocks


12

Variable and function naming

4 Choosing variable and function names carefully is the best way of making code selfdocumenting: s->method1(x) makes much less sense than peopleStack->push(person)

4 Long variable names mean more typing...

– ...but much less time debugging next year

4 They also need fewer comments to explain them


Avoid obscure constructs

4 Fortran ENTRY statements

– Sole purpose to reduce punched-card space...

4 Triple assign operator in C can be hard to read

– a = b & c ? d : e;

4 Operator precedence rules

– What is going on in n[i] *= *m++ - k*l & i++ + ++p->j++;

– Rewrite clearly using parentheses, or split into two statements

4 Operator overloading in C++

– Use only when it makes the code clearer


13

Obscurity ≠ efficiency

4 Generally speaking, compilers are pretty smart

4 Missing out the parentheses from x = a*(*p) + (b - *q) - (c*(*r) + d); will not make your code go faster...

4 Developer time is always more expensive than computer time

– Shortcuts taken now will come back to bite you later

4 Write code for humans, not compilers


4 Code should be commented

4

Code should be commented!

Comments


14

What comments are for

4 There is no “right” way to comment code

– But again, lots of wrong ways...

4 Important factors are consistency and readability

4 Comments should add information

4 Comments should be used in key places

– Function headers

– Variable declarations for important variables

– Key code blocks

– Tricky bits of algorithm


Think about comments

4 Think about comments as you write them: int i; /* an integer loop counter */ struct X *x[MAX]; is worse than useless; it’s also irritating!

4 Comments should not break up the “flow” of the code as read

4 They must also reflect the reality; if you change the code, change the comment !


15

Really think about comments

4 Take care commenting out code: do i = 1, n

C-enddo density(i) = density(i) + aux(i) density(i) = density(i)*1.2

4 Is this wrong? A fudge factor? Temporary?

4 Add extra comments explaining why code has been removed

– C-This applies if we use Williamson’s normalisation

4 Or remove it completely!


Code modularity

4 Modularity of source code has big impact on comprehensibility

4 Functional and data modularity should be driven by design

4 Some modularity decisions come into implementation

– Filenames

– Directory structure

– What code lives in which file

– Use of object libraries to collect code


16

Organising source code

4 Should make whole program structure as intuitive as possible

4 Use sensible, descriptive filenames

4 Collect related functions into single file

– eg. all i/o functions could go in input_output.f

4 If language supports header files, use wisely

– No implementation code in C++ headers...

4 And, of course, use revision control and a makefile


Organisation for an easy life

4 Organising compiled code into subdirectories and libraries is a good way to facilitate testing

– Have a main directory and subdirectories for each “module”

(user interface, simulation engine, database access, ...)

– Code in subdirectories compiles into a library

– Main code at top level links against the libraries…

– …and so does test code in the subdirectories

– Thus, module test code is cleanly separated from the main code

– And you know the test code is testing the right things, because it links against the final “real” code in the library!

– Module testing made cleaner, safer and more obvious to third parties!


17

In short...

4 Good programming style is about investing a little extra time now to save a bunch of time in the future

4 When writing code, ask yourself: “ if this landed on my desk, would I be happy to browse through it, figure out what it does and then maintain it ?”

4 If the answer is “no”, you should probably rewrite it


Beautifying tools

4 There are tools which can help with formatting and style

– When writing code (syntactic editors)

– When reading code (browsers and reformatters)

4 Below we look at a few of each

– We look at browsers in more depth in the final lecture


18

Simple reformatters

4 cb - C code beautifier

– Fairly standard Unix tool

– Reindents C program code

– Uses hard tabs for indentation, so is actually not so great...

4 ftrans - Fortran translator

– Fortran - Fortran translator

– Can convert, e.g. keywords → uppercase, variable names → lower

– Does much more too

– ftp://ftp.epcc.ed.ac.uk/pub/personal/spb/ftrans/


Syntactic editing tools

4 Emacs

– FSF/GNU project and others

– Syntactic modes for a wide range of languages

• Ada, C, C++, Fortran77, Fortran90, HTML, LaTeX, Lisp, Modula2,

Pascal, Perl, Prolog, Scheme, SGML, Simula, shellscript, Tcl, XML

– Customisable syntactic editing, highlighting and reformatting

– Code analysers available as add-ons (eg. OO-Browser)

4 JBuilder

– Inprise/Borland Inc

– Full Java development environment: browse, edit, build

– Syntactic highlighting of Java source code

– Builds class hierarchy diagrams


19

Syntactic editing tools

4 Developer Studio & Visual Basic

– Microsoft Inc

– Full development environments: browse, edit, build

– Builds class hierarchy diagrams for Visual C++ / Basic

– Good for understanding complex OO structure

– Editor auto-formats code (even auto-completes!)


Summary

4 Computer programs are complex

– Complex to write

– Complex to debug

– Complex to understand

– Complex to maintain

4 Adopting good practices can help

– Know a range of languages and how/when to apply them

– Adopt a sensible coding style

– Use comments and strive for self-documenting code

– Think about overall program and code structure

– Learn what tools are available and use them


20

Advanced Programming: Tools and Techniques

Language, Style and Practice

Code should be commented!

Related documents

Products

Support

Advanced Programming: Tools and Techniques

Language, Style and Practice

Code should be commented!

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib