It’s uncommon to see methods like this>
public Person findPerson() {
if(someService) [
return someService.getPerson();
}
return null;
}
There is no reason to make a Person object where there are no persons found. But doing so requires extra code in the client to handle the null value. This becomes a problem if a client is, for example, a GUI:
somePage.jsp
<%
...
Person person = myService.findPerson();
%>
<table>
<tr>
<td>${person.name}</td>
<td>${person.address}</td>
<td>${person.numberOfPurchases}</td>
</tr>
</table>
The result of such code in cases where the person cannot be found is Server error. So, there is no reason ever to return null from an object-valued method instead of returning an empty object. Especially if you deal with arrays and collections.
VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
How many times we write a program like this:
public void doSmth() {
Salary s = calculateSalary(Person p);
...
}
private Salary calculateSalary(Person p) {
return 100;
}
And so we hear from our sjef that we can’t have same salary for male and female. So we do this:
public void doSmth() {
Salary male = calculateSalary(Person p, true);
Salary female = calculateSalary(Person p, false);
...
}
private Salary calculateSalary(Person p, boolean sex) {
if(sex) return 100;
else return 50;
}
Yes, but what if we have more options later on? Or if we look just at the doSmth() function? What do these true/false mean?
An enum type in such cases makes your code easier to read and to write, especially if you are using an IDE that supports autocomplition. Also, it makes it easy to add more options later.
So here’s how we should do it:
public enum Sex {MALE, FEMALE}
public void doSmth() {
Salary male = calculateSalary(Person p, Sex.MALE);
Salary female = calculateSalary(Person p, Sex.FEMALE);
...
}
private Salary calculateSalary(Person p, Sex sex) {
if(sex.equals(Sex.MALE) return 100;
else return 50;
}
VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
I’ve recently come to a heuristic called the Law of Demeter (LoD) or Principle of Least Knowledge that says a module should not know about the innards of the objects it manipulates. More precisely, the method of a particular class should call:
- other methods of the same class
- objects created by the method itself
- objects passed as arguments to the method
- objects held in an instance variable of the same class
And that”s all!
So the following code appears to violate the Law:
String output = obj.getContext().getOptions().getDir().getPath();
It’s easy to forget something around such a structure. This one can solve the issue:
String output = obj.getPathFromContext();
VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
The book by Robert C. Martin “Clean Code” is a really very useful material for all programmers. You can disagree with him sometimes (as I do), but it still provides some useful notes that helped me to place my programmer experience and knowledge where they belong. Here I’ll provide some key notes that I did while reading the book and that I’d like to memorize.
What you as a programmer SHOULD DO:
1. Give everything meaningful, searchable and pronounceable names.
2. Use names that other programmers can understand. Remember that the code is for programmers, not customers.
3. Functions should be small and smaller than that.
4. Functions should do one thing. They should do it well. They should do it only.
5. The ideal number of arguments for a function is zero. Max 3.
6. Prefer exceptions to returning error codes. Create informative error messages.
7. Prefer meaningful names to comments.
8. Write JavaDoc only for public API’s.
9. Format your code. While working in a team use a single formatting style.
10. Test your code with clean tests. Remember that test code is just as important as production code.
11. Test just one concept per test.
12. Test should follow the FIRST rule:
Fast - tests should be fast.
Independent - tests should not depend on each other
Repeatable - tests should be repeatable in any environment
Self-validating – the test should have a boolean output
Timely - write unit tests before the production code.
What you as a programmer should AVOID:
1. Avoid encoding
2. Avoid duplicate code. Watch out not only duplicate functions but also duplicate functionality.
3. Avoid noisy, redundant, uninformative comments. Remember that one of the more common motivations for writing comments is bad code.
VN:F [1.9.13_1145]
Rating: 0.0/5 (0 votes cast)
