Hacker News Reader

Comment by einrealist | Hacker News Reader

My rules for good code:

1) Always write code for someone else. And you don't know who it is.

2) Write tests not only to prove correctness, but also to test whether code as an interface makes sense.

3) Be defensive as much as possible. Each additional check / assertion helps to avoid accidental bugs or can help to find them early.

4) Speak about code as much as possible. If you can explain code in your own words and discuss it with someone else, code gets raised on a philosophical level and may end up to be elegant and logical for others.

5) RTFM & RTFS(pecs)!

View on HN

Totally agree with this list. I would also add:

6) Read lots of code. The more of other people's code that you read the faster you'll learn good practices.

7) Work with other people that are better/more experienced than you.

8) Code reviews are your friend. When I was at Google, the best way to learn and teach good coding practices and libraries were through the code reviews that we had. Get in the practice of reviewing other people's code and having others review your code.

9) Test, test, test! It may sound counter intuitive, but if you want to increase coding velocity, write tests. Tests upfront will save so much time in debugging later on.

>6) Read lots of code. The more of other people's code that you read the faster you'll learn good practices.

How do you get to read "good code" outside of the job? Care to point me to some such java resources.

> > 6) Read lots of code. The more of other people's code that you read the faster you'll learn good practices.

> How do you get to read "good code" outside of the job?

You don't have to read just good code to learn good practices (negative examples are important, too), and there's lots of published code readily available (e.g., open source repositories.)

Though, I'd say you need to work with lots of code to learn good practices; merely reading code may give you misleading ideas of good vs. bad practices.

I usually look at GitHub, Reddit, or just links from HackerNews.

I have to nitpick.

2) You can't prove correctness with tests. You can only state that it ran correctly for that test case(s).

"Proving correctness" is sort of windmill-tilting for today. Just don't despair of this :)

Good test vectors are a great investment, as are constraint checks and supporting instrumentation of said constraint checks.

I don't despair, because I know that to prove correctness of a program you need to use math.

For example proof assistants(like Coq, Agda, Idris, hol) are capable of proving correctness of a program.

Well, usually my code does not run in space. ;)

But you are right, tests are biased. Pair programming can reduce the chance of code/tests being biased in a negative way.

No, I literally mean that you can't prove correctness with tests, because you would need a lot of test cases to prove the simplest function.

For example: int addOne(int input) function would need test cases for every number in the int type, which would be 2,147,483,647 * 2 + 1 test case.

The point of writing tests is to provide information, not prove correctness.

IE, a test is another way to explain what the developer of that test cared about, worried about, needed to verify of the code that is exercised.

Also, tests provide anothing built in consumer of the code, and all code with more consumers is better code, purely by surviving the stress.

It depends on the terms we set for our tests. Usually we infer things to be correct that are out of scope. For instance, my tests usually don't cover to test the runtime or hardware before executing tests. And what if laws of physics change? No seriously, I know what you mean. But I mean correctness in the bounds we set. Those bounds are different if you write software for aviation or biometric devices or an Instagram clone.

It's perfectly possible to write a function with a small enough set of arguments to make it practical to exhaustively test.

Well it's possible, but how many developer would rather make a new type for using the first ten integer instead of just using int?

I think random testing is a good way to get almost exhaustively tests.

A developer that uses a narrower integer data type, or who wants to be clear that the argument is a member of an enumerated set of options, not an integer. What kind of developer represents non-integer data as an integer data type?

> I think random testing is a good way to get almost exhaustively tests.

I think that testing known/predictable edge and corner cases makes more sense (in some cases), but I also think that I was responding to a comment about the impossibility of using tests to prove correctness of a function, not about how to derive practical benefits despite theoretical limitations.

You are right, I didn't think the example through.

You are right, you can use tests to prove a function if - the function has very limited arguments and - the function is pure or does very limited amount of state change(side effect)

Generally speaking tests are not the right tool for proving program correctness.

integers are frequently used to represent fixed point numbers anytime you're doing interesting math in an embedded system

And old PC hardware, where you aren't guaranteed to have an FPU, or where integer operations were a lot quicker than FP ones.

1) Always write code for someone else. And you don't know who it is. -- similarly: "When I come back to this in a few years after not touching this code, will I understand it?"

I would agree with (1), but add "Most code is read at least an order of magnitude more times than it is written." Lots of decisions that save you time writing code (or save typing) at the expense of reading the code are bad decisions because of this.

Also, always put a breakpoint on every code branch and step through it at least once in the debugger. Everyone makes mistakes. Fixing mistakes at the point of writing the code is much more efficient than having someone else fix them later. If you haven't done at least this level of testing, just don't check it in. Assume code is broken unless it has been tested.

Reply on news.ycombinator.com