Comment by pklausler | Hacker News Reader

Comment by pklausler | Hacker News Reader

When "better" means "fewest bugs":

1) Use the best language you can get away with. This means using a language that eliminates entire classes of run-time errors via some or all of:

  a) Strong typing

  b) Static typing

  c) Managed memory

  d) Immutable data

2) Assume that your code will be maintained by somebody who doesn't know your programming language as well as you do.

3) Use static and dynamic assertions liberally.

4) Ease debugging. Have great formatted dumps of your internal data structures, great internal consistency checking, and great logging. Automate problem isolation, too: for example, in an optimizing compiler, at each point where a discretionary change is about to be made, call a function that logs the change, increments a counter, and returns false if the counter is past a limit that you can set in the environment; this allows an automated bisection analysis to immediately find the change that broke a test program.

5) Regression tests. Once you fix a bug, make sure that your test suite will notice recrudescence.

6) Don't hire or retain sloppy programmers.

Point 6. freaks me out, because I am not sure if I am one of them.

Also, your first three points puts Ruby pretty much out of the picture.

EDIT: Mentioned Ruby because that's what I am working on right now, after Java and Scala

You can write buggy code in any language, and good code in any language. If Ruby's what you have to use, write good Ruby code. If the only reason you're not able to use something better is that you don't know anything better, then fix that when you can.

How exactly do the first five points put Ruby out of the picture? Sure, it isn't statically typed and allows mutable data, but I don't see how any of the remaining points couldn't apply.

True. First 3 points. Corrected.

You probably are not sloppy, because you are worried about being sloppy. The sloppy programmers are the ones that don't care about being sloppy. If you're conscientious, you have a huge leg up on a lot of other programmers.

Since 'sloppy' is going to be defined differently by basically everyone, this isn't true.

That someone is worried about being sloppy really only lets you assume they don't write code they consider sloppy.

Not even that. They could believe that they are in a job where they are expected to move at a pace that implies sloppy code.

Of course, that will actually mean they move much more slowly due to bug fixes, but a junior dev in an environment without a good senior dev can easily fall to the "quick and dirty" fallacy.

I'd add 7) Try not to make the same bug/mistake twice.

One of the most important things I learned from chess was to go back over your previous games and look for what mistakes you made, why you made them, and how you can avoid them next time.

Do this same analysis with every BUG you see a bug in your code(whether you wrote it or not). Ask yourself why you or someone else make this mistake? What is because they a assumed a method did something it didn't? Was it because the domain logic wasn't in a single easy to find place so they reinvted the wheel and did it incorrectly?

Remember also that even in 'C', there are strong and static typing ... aspects to most compilers lurking under the surface.

And for 4) - don't be afraid to build instrumentation into the code base to support decisions about correct operation.

This last part is sooo overlooked.

Whenever people talk about typing I just think about how C prevents none of the magical solutions they talk about.

I feel like this answer ignores why you are writing code in the first place.

The question was how to write better code.

It sure is :)

Reply on news.ycombinator.com