Clean Code

N6: 
Avoid Encodings
Names should not be encoded with type or scope information. Prefixes such as 
m_
or
f
are useless in today’s environments. Also project and/or subsystem encodings such as

---

313
Tests
vis_
(for visual imaging system) are distracting and redundant. Again, today’s environ-
ments provide all that information without having to mangle the names. Keep your
names free of Hungarian pollution.
N7: 
Names Should Describe Side-Effects
Names should describe everything that a function, variable, or class is or does. Don’t hide
side effects with a name. Don’t use a simple verb to describe a function that does more
than just that simple action. For example, consider this code from TestNG:
public ObjectOutputStream getOos() throws IOException {
if (m_oos == null) {
m_oos = new ObjectOutputStream(m_socket.getOutputStream());
}
return m_oos;
}
This function does a bit more than get an “oos”; it creates the “oos” if it hasn’t been cre-
ated already. Thus, a better name might be 
createOrReturnOos
.
Tests
T1: 
Insufficient Tests
How many tests should be in a test suite? Unfortunately, the metric many programmers use
is “That seems like enough.” A test suite should test everything that could possibly break.
The tests are insufficient so long as there are conditions that have not been explored by the
tests or calculations that have not been validated.
T2: 
Use a Coverage Tool!
Coverage tools reports gaps in your testing strategy. They make it easy to find modules,
classes, and functions that are insufficiently tested. Most IDEs give you a visual indication,
marking lines that are covered in green and those that are uncovered in red. This makes it
quick and easy to find 
if
or 
catch
statements whose bodies haven’t been checked.