Methods – Part 2

Part 2 – Unit 2: Methods (Computer Science 30S)

If you don’t feel like reading this web page, here are two alternatives:

  • Read this presentation of the same content (slides 33 – 45)
  • Watch this playlist of videos of the same content on YouTube

Content Sections:

  1. Returning from a Method
  2. Documenting Methods

Returning from a Method

  • If you need your method to return a value (in other words it isn’t a void method), you must include a return statement in the method body


  • This means that your method sends back (returns) the specified value in the method declaration


  • When the method is called, the returned result can then be used


  • void method does not return anything
  • You can also use a compound statement in the return statement
  • Rewriting and simplifying this method…


Documenting Methods

  • You use comments in methods just as in other code to clarify what the method will be doing
  • The documentation of methods will now be expected (and marked) on all programmer-defined methods you write
  • The traditional way to document methods could include up to 4 things:
    1. PURPOSE: A brief description of what the method is doing
    2. PRE: The preconditions
    3. POST: The post conditions
    4. CALLS: Any other methods this method calls
  • The PURPOSE should be brief and to the point
  • The PRE (preconditions) are any initial requirements the method needs (e.g. the parameters, needed global variables, etc.)
  • The POST (post conditions) are what will happen after the method has executed (e.g. the return value, changes to global variables, GUI changes, etc.)
  • The CALLS means in order to use this method, you must also have these methods as they are called by this method
  • For example…


  • However, many modern programming languages (including Java) have specific documentation techniques that often lend to easy web page documentation – in Java, this is called the JavaDoc style
  • NetBeans and other Java IDEs not only support this, but help automate the documentation process
  • JavaDoc is my recommended style for commenting methods (and classes)
  • It begins by typing /** on the line before the method identifier line, like this…
  • Here is the method, then you type /** on the line before the method identifier line and hit enter – NetBeans will fill in the details of what you need to comment


  • You now will fill in a general description of the method, then if it has parameters those will need to be commented (identified with @paramand if the method returns a value if will need to be commented (identified with @returnlike this…


  • NetBeans (and other IDEs) will only suggest what you need to comment and omit things that do not
  • Some of the other available JavaDoc tags you might see (or could always add) include:
    • @author – used in the class JavaDoc for your name
    • @version – the version software (1.0, 2.0, etc.)
    • @since – a way to date classes (or even methods)
    • @see – a way to link to other documentation
  • As well, in the general description area, Java treats it like HTML, so HTML tags can be used – here is an example of a JavaDoc before a class identifier…


The NEXT thing to work on is the “Methods Example 2” example page