Only recently did I notice that a file named libpeerconnection.log had suddenly appeared in my ~ directory, and it was empty.

I’d done so many things over the past few days—who knew which action was responsible?

I deleted it, finished what I was doing, and shut down. — Fine, I guess my curiosity isn’t that strong.

After rebooting, I suddenly found that thing had appeared again. What was going on? Some weird setting in a commonly used program?

A quick Google turned up a lot of information. Following the links, it became clear that chrome did it; Chrome said chromium did it. Either way, the culprit was found.

Following that lead, I quickly found this issue, which pointed to the source of the bug: <tommi@chromium.org>. This person submitted a commit, and inside it was the following alarming snippet.

 

C
diff --git a/third_party/libjingle/overrides/initialize_module.cc
b/third_party/libjingle/overrides/initialize_module.cc
....
+  if (CommandLine::Init(0, NULL)) {
+#if !defined(OS_WIN)
+    // This is not needed on Windows since CommandLine::Init has already
+    // done the equivalent thing via the GetCommandLine() API.
+    CommandLine::ForCurrentProcess()->AppendArguments(command_line, true);
+#endif
+    logging::InitLogging(
+        FILE_PATH_LITERAL("libpeerconnection.log"),
+        logging::LOG_TO_BOTH_FILE_AND_SYSTEM_DEBUG_LOG,
+        logging::LOCK_LOG_FILE,
+        logging::APPEND_TO_OLD_LOG_FILE,
+        logging::DISABLE_DCHECK_FOR_NON_OFFICIAL_RELEASE_BUILDS);
+  }
.....

Screw your whole family—nothing even happened, yet you start by generating a .log file in the current directory?

If that’s how you do things, should GTK also generate dozens of binary files in my /boot directory at every boot just to prove its worth?

===============================================================================

We know that everything in the world comes at a cost. Because of efficiency, what we pay is often much more than what we gain—and by quite a margin.

It’s the same with code. To solve a problem, we often face trade-offs: space for time? time for space? elegance for performance? performance for elegance? A weird syntax, or a more maintainable implementation that’s slightly less efficient?

Whatever choice we make, it should follow these principles:

  1. The cost must bring rewards. For example, a piece of code that uses much more memory to solve the same problem—if it isn’t faster, what’s the point?
  2. The cost should be acceptable. For example, if speeding up Chrome means trashing things in my lib directories, that’s obviously unacceptable.
  3. If possible, the choice should be left to the end user. In this case, give me a config file to let me choose whether to log and where to log. Would that kill you?

Take this time, comrade <tommi@chromium.org>, do you know the first thing I type after booting? It’s ls.

And do you know the first directory I go to after booting? It’s ~.

Every time I see this “wise” piece of code of yours and that idiotic log file, I can’t help thinking: this guy must have come from the government.