We will now write our own methods. It somehow comes down to extending the buggle vocabulary by teaching it new tricks.
For example, we saw in a previous exercise how to ask the buggle to go get
the baggle in front of it, and bring it back. If there is several baggles on
the board, and if we want to bring all of them on the bottom line, you have
to repeat this code several times, or include it in a loop. In any case, you
should avoid to duplicate your code to keep it pleasant to read and easily
understandable. It would be better if the buggle could obey an
goAndGet()
order just like it understands a
[!c]stepForward()[/!][!scala|java|python]forward()[/!]
one.
The [!thelang] syntax to write a simple method called goAndGet
is the following:
[!java|c]void goAndGet() {[/!][!python]def goAndGet():[/!][!scala]def goAndGet() {[/!] actions()[!java|c];[/!] to()[!java|c];[/!] do()[!java|c];[/!] [!java|scala|c]}[/!]
The method body [!java|scala|c](between curly braces)[/!][!python](the
indented block)[/!] will be executed when we call the method later on (that
is, when we write goAndGet()
somewhere in our code). This
method body can contain as many instructions as you want, and any
construction we saw so far (for, while, if, etc). [!java|c]The
void
keyword means that this method does not return any
result. For example, the isOverBaggle()
method does return a
result, which is a [!c]int[/!][!java]boolean[/!] indicating whether or not
the buggle is located over a baggle. We will soon learn to define such
methods too. For now, just write void
at this location.[/!]
You should strive to document your code to keep it readable. When you write it, its purpose and limitations are clear to you, but most of the time, this does not last for long. You will soon forget about the details of every specific method, and this day you will be happy to read its documentation. In the following example, we use the specific formalism of [!java]javadoc[/!][!scala]scaladoc[/!][!python]pydoc[/!], a program that extracts the documentation of [!thelang] source code to produce html pages. The main advantage is that it allows to keep the documentation near to the code. So, when you change your code, you have less chances to forget to update the documentation.
[!java|scala][!java]javadoc[/!][!scala]scaladoc[/!] comments begin with the
/**
marker (with two asterisks). They must be placed right
before the method they document for the tool to find them.[/!]
[!python]pydoc comments should be placed at the beginning of the method body
so that the tool finds them. They should be placed between """
,
which mark multi-line strings in python.[/!] The first line should be a
brief description of what this method does while any subsequent lines should
provide any important details about the method.
[!java|scala]/** * Go, retrieves the baggle in front of the buggle, and brings it back * * Does not check for walls, so be careful to not call it when walls are present. */[/!] [!java]void goAndGet() {[/!] [!scala]def goAndGet() {[/!] [!python]def goAndGet(): """Go, retrieves the baggle in front of the buggle, and brings it back. Does not check for walls, so be careful to not call it when walls are present."""[/!] actions()[!java];[/!] to()[!java];[/!] do()[!java];[/!] [!java|scala]}[/!]
Most programming language forbid the use of spaces in method and variable identifiers (=their names). Accented letters are sometimes allowed (as in [!thelang]), but they can lead to portability issues between operating systems and should thus be avoided when possible.
Across all programming languages, there is two main conventions to name variables and methods. The first one, consists in concatenating all words with only the first letter of each word in upper case. "go and get" becomes goAndGet(). It is called CamelCase because identifiers written this way graphically remind of a camel back. The other convention, called snake_case, is to write every words in lower case, separated with underscores symbols (_). "go and get" becomes go_and_get().
Which convention to use is the topic of heated discussion across developers, but each programming language has its own habits. In Python, Perl and the C language, the snake_case is often used for methods and variables. Java and Scala prefer the lowerCamelCase (the very first letter is lower case) for that.
The CamelCase convention is used everywhere in PLM because this program is written in Java itself, so we kept our habits when adding new languages. But the fact that the Python bindings of PLM use the CamelCase instead of the snake_case is considered as a bug that we will fix in further releases.
The goal of this exercise is to write a method called
goAndGet()
which does the same than in a previous exercises
(move forward until over a baggle, pick it up, move back to initial
position, drop baggle).
This exercise is a bit different because you will not write all of the code
executed by the buggle. Instead, you should only write one method that get
called automagically added when you click on Start. Your buggle calls
your goAndGet()
method on each row, until the baggle is
found. [!python|scala]The code for that is already provided under the
goAndGet()
method, but you probably don't want to change
it.[/!] [!java]You don't need to write the code calling
goAndGet()
yourself. It's automagically there already, even if
you cannot see it.[/!]
But for that to work, you have to actually write this
goAndGet()
method now.