Live data from Hacker News

The Most Important Code Isn't Code

zachholman.com

81–83 of 83 posts

Re: The Most Important Code Isn't Code

#81
post #48

Earlier quoted context omitted.

If the general behavior of multiplex isn't clear to the api-user from the example: multiplex('Tom', 4) == 'TomTomTomTom' I'd argue that's a failure of the api designer that no amount of documentation is going to make up for. Examples are good, testing is good, executable, testable documentation is doubly good, and predictable, intuitive api interfaces are invaluable; everything else is a liability that is going to go…

What is the expected behavior of, say, multiplex('Tom', 0) or multiplex(null, 2) ?

Well, if the function was designed by me, then the completely obvious answers are '' and a NullPointerException. Anything else is bug-prone — if the first case does something different, then nearly every caller of the function will need to check to see if the count is zero, or it will get behavior for that case that is not correct for its purposes; and if the second case does something different, then the function is choosing to provide incorrect output instead of crashing.

Also, I would have called it something different.

However, over the years, I've learned that many things that are obvious to me are not, in fact, true. So, what are the arguments for any other possible behavior?

Re: The Most Important Code Isn't Code

#82
post #81
post #48

Earlier quoted context omitted.

What is the expected behavior of, say, multiplex('Tom', 0) or multiplex(null, 2) ?

Well, if the function was designed by me, then the completely obvious answers are '' and a NullPointerException. Anything else is bug-prone — if the first case does something different, then nearly every caller of the function will need to check to see if the count is zero, or it will get behavior for that case that is not correct for its purposes; and if the second case does something different, then the function is…

Backward compatibility could be one such factor.

In any case, documenting edge conditions helps in code maintenance.

Re: The Most Important Code Isn't Code

#83
post #82
post #81

Earlier quoted context omitted.

Well, if the function was designed by me, then the completely obvious answers are '' and a NullPointerException. Anything else is bug-prone — if the first case does something different, then nearly every caller of the function will need to check to see if the count is zero, or it will get behavior for that case that is not correct for its purposes; and if the second case does something different, then the function is…

Backward compatibility could be one such factor. In any case, documenting edge conditions helps in code maintenance.

Since I'm coming from Python, JS, and C, passing a null instead of a string doesn't seem like an "edge condition"; it's the same kind of error as passing an integer or Map instead of a string. Passing 0, I suppose, is an edge condition.
Post reply on HN