4 ms·
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 wh
by einrealist 10y ago
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)!
- Johnie 10y agoTotally 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.
- aryamaan 10y ago>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.
- dragonwriter 10y ago> > 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.
- Johnie 10y agoI usually look at GitHub, Reddit, or just links from HackerNews.
- voiper1 10y ago1) 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?"
- jstelly 10y agoI 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.
- StrykerKKD 10y agoI have to nitpick. 2) You can't prove correctness with tests. You can only state that it ran correctly for that test case(s).
- einrealist 10y agoWell, 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.
- StrykerKKD 10y agoNo, 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.
- misttar 10y agoThe 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.
- einrealist 10y agoIt 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.
- ArkyBeagle 10y ago"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.