4 ms·

Common Mistakes Developers Make

16 points by kirtijthorat 13y ago

jrockway 13y ago
Mistake number 1: not writing any tests. I was watching some anime last night where the characters were trying to make a computer game for some contest. They finished it, but it was too buggy to play through to the end without crashing (or causing the computer to restart, not sure how they managed that one), and they decided it would be impossible to fix them all because the game takes five hours to play through all the way. This is a common error, not one committed at random by a bunch of fictional high school students. You should never need to use your program to check that it doesn't crash after you've made changes. Your tests should cover this. If you're loading up your web browser to see if your sort routine works, you're wasting your time again and again. You have a computer that can be programmed to do anything you want. Tell it to do what you would do if you were playing your game or using your website. Then it can test your code thousands of times a second, instead of once every five hours. </rant> This is also a good check to see if your code is reusable. If you can't reuse parts in isolation to test your program, you're probably not going to be able to reuse them in another program.
- GuiA 13y ago
  What's the anime?
  - jrockway 13y ago
    The second-to-last episode of Oreimo.
- thirsteh 13y ago
  > I was watching some anime last night where the characters were trying to make a computer game for some contest. They finished it, but it was too buggy to play through to the end without crashing (or causing the computer to restart, not sure how they managed that one), and they decided it would be impossible to fix them all because the game takes five hours to play through all the way. I don't disagree that tests (especially fuzz tests) are essential, but this is a problem with dynamic and unsafe (unrestricted side-effects) languages, not languages in general. You're very unlikely to write a program in a language like Haskell, have the program compile, and then not work as expected.
  - jrockway 13y ago
    Not true at all. Consider this implementation of a function that checks if a string is a palindrome: is_palindrome :: String -> Bool is_palindrome _ = True You still have to test it.
    - thirsteh 13y ago
      My statement that you're unlikely to experience problems if you write something in a language with so many compile-time checks isn't "true at all"? Really? And if you really want to argue about silly examples, we can talk about Agda instead, a language in which even your contrived example wouldn't need any unit tests. I never said that you didn't need tests at all, or that you couldn't deliberately write programs that didn't work. I'm just of the opinion that the heightened focus on unit tests is a symptom of a language that doesn't perform such checks for you automatically. I also very strongly disagree with your insinuation that you need unit tests. Fuzz tests can be much more powerful.
      - jrockway 13y ago
        I've written plenty of production software in statically-typed languages, including Haskell. I write about as many tests for them as I do in other languages. Having also written a lot of Python, I don't find my software dying unexpectedly from AttributeErrors. Instead, it merely produces the wrong answer because the wrong code was in the method. The advantage the compiler brings is the ability to refactor. With tests, you don't know if you've gotten everything. But if you change a method signature in, say, Java; you'll know immediately when you run the compiler. But it doesn't mean your program will produce the right answer, it only means that you're calling the function with the right number of arguments of the right types.
        thirsteh 13y ago
        You're disagreeing very passionately with points I never made. I literally said "I don't disagree that tests are essential." I followed that up with the statement that programs written in languages with compilers that perform a lot of checks at compile time tend to work as expected, to which you responded with "not true at all," and gave an extremely contrived example of something that "needs to be tested."
adamnemecek 13y ago
This article is an equivalent of a Cosmo article for developers.
- thirsteh 13y ago
  At least it's not suggesting you poke your pair programming partner with a fork to increase... productivity.
  - jrockway 13y ago
    You should have called it "reproductivity".

16 points by kirtijthorat 13y ago

Mistake number 1: not writing any tests. I was watching some anime last night where the characters were trying to make a computer game for some contest. They finished it, but it was too buggy to play through to the end without crashing (or causing the computer to restart, not sure how they managed that one), and they decided it would be impossible to fix them all because the game takes five hours to play through all the way. This is a common error, not one committed at random by a bunch of fictional high school students. You should never need to use your program to check that it doesn't crash after you've made changes. Your tests should cover this. If you're loading up your web browser to see if your sort routine works, you're wasting your time again and again. You have a computer that can be programmed to do anything you want. Tell it to do what you would do if you were playing your game or using your website. Then it can test your code thousands of times a second, instead of once every five hours. </rant> This is also a good check to see if your code is reusable. If you can't reuse parts in isolation to test your program, you're probably not going to be able to reuse them in another program.

GuiA 13y ago
What's the anime?
- jrockway 13y ago
  The second-to-last episode of Oreimo.
thirsteh 13y ago
> I was watching some anime last night where the characters were trying to make a computer game for some contest. They finished it, but it was too buggy to play through to the end without crashing (or causing the computer to restart, not sure how they managed that one), and they decided it would be impossible to fix them all because the game takes five hours to play through all the way. I don't disagree that tests (especially fuzz tests) are essential, but this is a problem with dynamic and unsafe (unrestricted side-effects) languages, not languages in general. You're very unlikely to write a program in a language like Haskell, have the program compile, and then not work as expected.
- jrockway 13y ago
  Not true at all. Consider this implementation of a function that checks if a string is a palindrome: is_palindrome :: String -> Bool is_palindrome _ = True You still have to test it.
  - thirsteh 13y ago
    My statement that you're unlikely to experience problems if you write something in a language with so many compile-time checks isn't "true at all"? Really? And if you really want to argue about silly examples, we can talk about Agda instead, a language in which even your contrived example wouldn't need any unit tests. I never said that you didn't need tests at all, or that you couldn't deliberately write programs that didn't work. I'm just of the opinion that the heightened focus on unit tests is a symptom of a language that doesn't perform such checks for you automatically. I also very strongly disagree with your insinuation that you need unit tests. Fuzz tests can be much more powerful.
    - jrockway 13y ago
      I've written plenty of production software in statically-typed languages, including Haskell. I write about as many tests for them as I do in other languages. Having also written a lot of Python, I don't find my software dying unexpectedly from AttributeErrors. Instead, it merely produces the wrong answer because the wrong code was in the method. The advantage the compiler brings is the ability to refactor. With tests, you don't know if you've gotten everything. But if you change a method signature in, say, Java; you'll know immediately when you run the compiler. But it doesn't mean your program will produce the right answer, it only means that you're calling the function with the right number of arguments of the right types.
      - thirsteh 13y ago
        You're disagreeing very passionately with points I never made. I literally said "I don't disagree that tests are essential." I followed that up with the statement that programs written in languages with compilers that perform a lot of checks at compile time tend to work as expected, to which you responded with "not true at all," and gave an extremely contrived example of something that "needs to be tested."

adamnemecek 13y ago

This article is an equivalent of a Cosmo article for developers.

thirsteh 13y ago
At least it's not suggesting you poke your pair programming partner with a fork to increase... productivity.
- jrockway 13y ago
  You should have called it "reproductivity".