Jeanne Boyarsky

As programmers, there are some tasks we need to do frequently. For example, going through data and applying a condition are common. Here are two ways to count how many positive numbers are in a list:

public int loopImplementation(int[] nums) {
  int count = 0;
  for (int num : nums) {
    if (num > 0) {
      count++;
    }
  }
  return count;
}

public long streamImplementation(int[] nums) {
  return Arrays.stream(nums)
               .filter(n -> n > 0)
               .count();
}

Both of these accomplish the same thing, and they both use common Java idioms. An idiom is a common way of expressing some small piece of functionality that the community has general agreement on. Knowing how to write these quickly without having to think about them enables you to write code much faster. As you write code, look for patterns like these. You can even practice them to get faster and learn them by heart.

Some idioms, like looping, conditions, and streams, apply to all Java programmers. Others are more specific to the types of code you work on. For example, I do a lot with regular expressions and file I/O. The following idiom is one I commonly use in file I/O. It reads a file, removes any blank lines, and writes it back:

Path path = Paths.get("words.txt");
List<String> lines = Files.readAllLines(path);
lines.removeIf(t -> t.trim().isEmpty());
Files.write(path, lines);

If I were on a team where files didn’t fit in memory, I’d have to use a different programming idiom. However, I deal with small files where this is not an issue, so the convenience of four lines to do something powerful is worth it.

Notice with these idioms that much of the code is common regardless of your task. If I want to get negative numbers or odd numbers, I just change the if statement or filter. If I want to remove all lines that are more than 60 characters long, I just change the condition in removeIf:

lines.removeIf(t -> t.length() <= 60);

Regardless, I’m thinking about what I want to accomplish. I’m not looking up how to read a file or how to count values. That’s an idiom I learned long ago.

An interesting thing about idioms is that you don’t always learn them intentionally. I never sat down and decided to learn the idiom for reading/writing a file. I learned it from using it a lot. Looking up information repeatedly helps you learn it. Or at least helps you know where to find it. For example, I have trouble remembering the regular expression flags. I know what they do, but mix up ?s and ?m. I have looked it up enough times that I know I should google “javadoc pattern” to get the answer.

In conclusion, let your brain serve as a cache. Learn the idioms and common library API calls. Know where to look up the rest quickly. This will free you up to let your brain work on the hard stuff!