Marks of a Good Developer

• Knows when and how to log.

Dichotomy of Code and Comment

Instead of,
{CODE()}
public void validateUser(User user) {
//TODO: Implement this.
}
{CODE}
why not make it more intelligent to tools,
{CODE()}
public void validateUser(User user) {
Comments.todo("Implement validation of user.");
}
{CODE}
Some other examples,
{CODE()}
public class Person {
...
public void load(File file) {
ObjectInputStream objectInput = new ObjectInputStream(file.getInputStream());
Person person = null;

//Instead of:
try {
person = (Person) objectInput.readObject();
} catch(ClassNotFoundException e) {
//This will never happen...
}

//Why not:
try {
person = (Person) objectInput.readObject();
} catch(ClassNotFoundException e) {
Comments.impossible("This method is inside the very class definition.");
}
}
...
}
{CODE}

Both ways of doing things are documenting the same idea to the programmers, but the comment based approach is unintelligent to compilers and other tools, while the method call annotation is searchable by code structure, and may even allow runtime control (Imagine implementing the Comments.impossible method to log assertion violation).

Note: This is similar to how some tools like JavaDoc and xDoclet run the JavaDoc documentation, but this still doesn't have as direct of an effect as a straightforward method call (not to mention programmers are immediately familar with their own method call, while learning all those annotation-based tools require time and effort).

Most Good Advices in Life are Statistical (including this one)

• Life is a heuristic.
• C.f. stock market investment advice.

Job Interview: The Process of Selection vs. Elimination

• College's Office of Admission vs. "Rejection."

Why Do Unit Testing?

This is my attempt to convinence myself to write unit testing code consistently.

• You can write sloppy production and test code, and still come out with higher quality.
• Force you to think, design, and make modification to the code base systematically, rather than spontaneously.

Unit Testing Code Convention.

When writing unit testing code (in JUnit), I follow the following conventions.

• Group the sections of code by test cases. For example,

{CODE()}
public void testGetSetName() {
final String NAME1 = "Peter";
final String NAME2 = "Crystal";
Person person = new Person();

/* Test setting and getting the name. */
person.setName(NAME1);
assertEquals(NAME1, person.getName());
assertNotEquals(NAME2, person.getName();

/* Test null case. */
try {
person.setName(null);
} catch(IllegalArgumentException e) {}
}
{CODE}

In the above code, the grouping is that the statement that modifies the business/domain object starts one section, and one or more assertion statements immediately follow that test code.

Indirect Statements

• I think that I think that I think that A is true =? I think A is true
• I believe that I believe that I believe that S is true =? I believe S?
• I schedule to schedule to schedule to work =? I schedule to work?