Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't write bugs

teamten.com

Post reply on HN
Print view View original

61–70 of 113 posts

Re: Don't write bugs

#61

Post by pornel »

> After writing a few lines of code (3 to 6 lines, a short block within a function), re-read them.

That's insufficient in a lot of codebases in a lot of languages. Addition of a few new "locally-correct" lines can break something else in a completely different part of the code.

A trivial example: You've had a correctly-working program, you change a value of a field using correct calculation, and your program becomes incorrect — because other function elsewhere assumed this value won't change.

To avoid this you'd need to re-read the whole program after introducing any change, and that gets exponentially harder.

Re: Don't write bugs

#62

Post by IshKebab »

code_biologist wrote: post #11
bombcar wrote: post #5

At first glance this may sound like advice for a baseball player - “don’t strike out” - but that’s exactly what good players do - they work at identifying the things that get them to strike out and try to minimize them. Tony Gwynn spent hours reviewing tapes of his at bats. Keeping a log of your mistakes and analyzing them is helpful in any number of things, including coding. Can you not write any bugs? Probably not.…

It really annoys me that whenever I argue for "don't write bugs" as a quality practice, people immediately respond with all sorts of justifications why that's not possible. Of course it's not. But that doesn't mean we can't improve. We spend time and money on CI, linting systems, sprint retros — so the allergy to "think more carefully about what you wrote" surprises me.

"Don't write bugs" implies it is possible to write substantial code with no bugs, which isn't true (despite what this guy says).

You should say "try really hard not to write bugs" which is what you actually mean.

Re: Don't write bugs

#63

Post by raxxorrax »

If I would write down every bug I produced I would have filled a decently sized book by now.

But debugging has some additional functions. If you interface your standard wep-api, you might want to take a look at the response. Yes, you could do that without a debugger, but I would argue it is more convinient. That expands to anything that is a blackbox to you.

Stopping execution and taking a look at the state of the program is a decent tool I would not want to miss.

In some languages you have an insane amount of dependencies and you need something to evaluate the behavior of those submodules.

For pure algorithmic and determinist programs the statement of Dijekstra is true, but you often don't have it in reality. A server sending you garbled responses might garble you program too.

You also become blind to your own code. You think it does something that isn't reflected in code. You think this regex certainly matches the input, but it just doesn't because you forgot something. Reading again might not help.

Re: Don't write bugs

#64

Post by raxxorrax »

Xen0byte wrote: post #55

Firstly, I stopped taking this article seriously at "modern language (Java)". Apart from that, "we can decide to not put bugs in the code" is the most non-sensical thing I've ever read. OK, sure, you can eventually flush some or most bugs out before your code goes in for proper testing from formally-trained QA people, but unless all you're writing is "Hello World" applications or walking skeletons then writing bug-fr…

In the grand scheme of things Java is a modern language although I dislike how generations of langauges are defined.

But the innovation Java brought is larger than what younger languages bring to the table. You can still dislike the language of course.

Re: Don't write bugs

#66

Post by raxxorrax »

mkl95 wrote: post #8

> My Junior year of college I joined the programming team. School and the software industry are different beasts. Once the pressure of "real life" kicks in, your brain starts to work differently, often trading some of that academic brilliance for other things you need to survive. Ironically, I have seen some of the best code quality at places with crappy salaries. These companies are aware that they cannot compete wi…

Same experience here. Software quality outside pure software houses is often better, but the companies pay less. Sure, the scope is completely different in most cases.

Re: Don't write bugs

#68

Post by Joker_vD »

legerdemain wrote: post #7
OccamsMirror wrote: post #2

I thought there'd be something meatier than "don't write bugs" and "reread your code" but I was wrong.

I think the author put specific recommendations into their own sibling posts, accessible from this table of contents: https://www.teamten.com/lawrence/programming/

These are all actually good advice. Even "Avoid fields for communication between methods" although there are enough cases where it's better than the proposed alternative: when you have the method's implementation split into 10 private methods that need to pass 4-5 different pieces of data (for a total of 10-15 pieces) between each other, it's easier to just invent a private Context object, shove the data into its fields, attach those methods to it, and implement the public method as "return = new Context(...).doWork();".

Re: Don't write bugs

#69

Post by karmakaze »

raxxorrax wrote: post #64
Xen0byte wrote: post #55

Firstly, I stopped taking this article seriously at "modern language (Java)". Apart from that, "we can decide to not put bugs in the code" is the most non-sensical thing I've ever read. OK, sure, you can eventually flush some or most bugs out before your code goes in for proper testing from formally-trained QA people, but unless all you're writing is "Hello World" applications or walking skeletons then writing bug-fr…

In the grand scheme of things Java is a modern language although I dislike how generations of langauges are defined. But the innovation Java brought is larger than what younger languages bring to the table. You can still dislike the language of course.

One of the great ways of avoiding bugs is to make invalid states unrepresentable. An easy win is to use sum types for the various different flavours of a valid input parameter. The verbosity of having to manually create classes, wrap/unwrap rather than defining at-hoc in-place, and pattern matching leaves it in still the not modern camp, among other things.

Re: Don't write bugs

#70

Post by UncleMeat »

code_biologist wrote: post #11
bombcar wrote: post #5

At first glance this may sound like advice for a baseball player - “don’t strike out” - but that’s exactly what good players do - they work at identifying the things that get them to strike out and try to minimize them. Tony Gwynn spent hours reviewing tapes of his at bats. Keeping a log of your mistakes and analyzing them is helpful in any number of things, including coding. Can you not write any bugs? Probably not.…

It really annoys me that whenever I argue for "don't write bugs" as a quality practice, people immediately respond with all sorts of justifications why that's not possible. Of course it's not. But that doesn't mean we can't improve. We spend time and money on CI, linting systems, sprint retros — so the allergy to "think more carefully about what you wrote" surprises me.

I think it is the opposite. The reason we spend time and money on linting or CI is because we know people write bugs. If "don't write bugs" was an option we wouldn't need to spend that time and money. Good engineering practices should make systems that are resistant to human error.
Post reply on HN