Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I haven't heard the argument about making code deliberately hard to understand either.

I agree that clearer code and/or commenting would have been suitable.

I only latched on to the example because they specifically mentioned that the code wasn't commented. In this case, a few lines of comments might have helped them find what they were looking for. Even if they original programmer was one of those people who just can't stop writing code like:

  $a = ($b)?($ab):$c;
  d($a);
Maybe some amount of convincing could lead them to leave a comment every once in a while so we can at least get:

  // Detect collision
  $a = ($b)?($ab):$c;
  d($a);
Since it seems like both clear code and comments were absent, either one would have been helpful.


I don't think comments are any kind of substitute for clear, well-structured code. In your example, "Detect collision" still doesn't give me any kind of epiphany about the code. At best, it gives me a slight hint about where to go to get more information. Chances are I'm trying to fix a bug or change the behavior, so I still need to figure what $a, $b, $ab, $c, and d are and what their purpose is.

In other words, I have nothing against good comments, especially on obscure code, but I think they're only marginally useful even in those cases.


Definitely. I wasn't trying to say that they were a substitute. I specifically said both could have worked. In the example they cited, they couldn't even find where to begin. A small comment could have done something about it.

When you can't have both clear code and commenting, you could at least try to do one every once in a while. How can that be a bad thing?




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: