5 ms·

Programming Mistakes

• lucisferre 13y ago
  I'd argue these are examples of bad habits rather than outright mistakes (and yes, there is a difference).
• at-fates-hands 13y ago
  "Sometimes, the code you are copying may be so large that you don't have time to understand it completely. If you copy any code this way, there is a risk of making your applications vulnerable and buggy." This used to be a big one for me. About 6 months ago, I saw a presentation on hacking CMS' and how vulnerable they are. One of the main points was to make sure you pen test third party applications before you install and use them. It was a big eye opener for me. I'm no longer just assuming the authors did their due diligence and made sure their apps or plugins are secure before releasing them.
• cheery 13y ago
  Copy-pasting code without understanding is functionally same as importing large libraries or linking to them. You'll have same problems even if you didn't copy anything! This is why good programmers review code and prefer open source. His advice about copying is entirely wrong, because even if you don't understand some code, it can still be okay to use it in your project. The biggest problem with copying is that you easily get more lines of code you have to maintain. This is especially bad if you copy large chunk of code, which may improve later. If that happen you have to do the copying again to get the improvements. Link or import the code you need instead!
• tlongren 13y ago
  I stopped reading at "more better".
  • vowelless 13y ago
    You're penalizing a non-native English speaker for minor English grammatical problems? Why not offer to help him instead?
    • tlongren 13y ago
      I didn't penalize him. I just couldn't read past there. I actually upvoted him. lol.
  • chc 13y ago
    I stopped reading at "I stopped reading," because what follows is pretty much never insightful.
• cheery 13y ago
  I've been always better off by starting with an empty file. It lets me concentrate on the problem I am solving, with no fringes or bells that belong to the finished product. Also starting from scratch is great if you're stuck. If something prevents this behavior, you're better off by tossing it away. I think he should rather state to think clearly. You should always think for yourself about using a library. Does it fit your needs? Use it. If it doesn't, do not use it. You will not save time or your mind by using something that doesn't fit.
  • LanceH 13y ago
    Using a library is just one giant copy/paste, right?
• touristtam 13y ago
  ok, but this wall of text is not very nicely formatted.
• mataug 13y ago
  While I appreciate the writer's intention to write about these things,but I wish he had read the article titled "5 mistakes never to make as a novice writer".To put it bluntly, Its way too long and preachy. I am no saint myself though. Anyway the points put forth are quite right.
  • 1wheel 13y ago
    Or used a non link baity title.
• danso 13y ago
  I have to disagree with a lot of these "mistakes"...in certain (many) contexts, they might be actual mistakes...but sometimes they are necessary and efficient practices. As someone has said already, copying-and-pasting code is little different than implementing a library...and I'll be the first to admit that I don't understand how many of the libraries I use work underneath...but what I do understand is the ability to read tests/specs and see if the library behaves as it should, regardless of how it works underneath the hood. And I would say "searching for a fix on Google" is almost always the first thing a beginner should do. Some bugs are just undecipherable (segmentation faults in Ruby, for example) and could result for reasons that are far beyond a beginner's knowledge. At least with Google, you have a chance of finding a solution, and being good at Googling helps you also get better at recognizing the relevant parts of an error message (i.e. don't include your local variable names in your Google search). The one mistake that the OP omitted...and I think this is a huge one...is that beginners try to do too much. They want to build a Rails app...OK, fine, but they don't realize there's a lot of middleman steps worth doing before launching an app...such as organizing/visualizing the data, or deploying a simpler stack, etc., that all builds toward the goal of making a Rails app. And this is the way it is with method composition. Don't make a method that scrapes data, parses it, and stores it into a hard-coded named database....write a method that contacts the website, another method to read the appropriate section of the site, then another method to parse it, line by line, and then a host of methods that acts on each line: cleaning, validating, and storing it. When working with beginners, I find that there is a great inability to see how that last unit method fits into the bigger picture...because it just seems like that line-focused method should be a part of all the other methods...and yet that is where madness lies...I would argue that all of the other 5 mistakes mentioned by the OP stems from this inability to understand orthogonality.
  • k3n 13y ago
    With respect to "searching for a fix on Google", I think you made a logical jump that caused you to overthink it -- he specifically mentions programming -- as opposed to _debugging_, which is what you seem to be getting at. While debugging is indeed an aspect of programming, I think the author was specifically speaking to programming. And in that case, I couldn't agree more: if you have a programming challenge, you should at least make an honest attempt at it before consulting Google. Don't waste a lot of time on your own, but at the same time, at least give it a shot.
• cheery 13y ago
  If you stumble upon a new problem that's unknown to you, you should ALWAYS search what others have done. Only after that you'll try yourself if necessary, knowing the mistakes others made. Good programmers are lazy. You won't challenge your mind any more by not searching, that way you're just being stupid. Besides, it's much easier to create original works if you know what's original and what's not. This is why you should be studying other's work before you do your own.
  • mattmanser 13y ago
    Why have you made 3 posts on this thread?
    • cheery 13y ago
      They contain different points I noted, in the pace I discovered them. I can do as many posts as I want, do I? Or did you mean that I can EDIT the single post, until it contains everything I want to tell? Sorry. I did not figure that out until now.
      • dllthomas 13y ago
        Really if they're self contained, I prefer different points in different posts; makes it much easier to see what people are replying to.
• sonabinu 13y ago
  I think the one about googling before trying is so true!
• hvs 13y ago
  Please review the submission guidelines for HN: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
  • rs_ 13y ago
    My mistake. Shouldn't have included the number in title. If any moderator is reading this, please change the title. I can't edit it myself. Thanks :)
• cheery 13y ago
  What's the point of having warnings in the first place, if you treat them as errors? Also what's the point of having errors that prevent you from executing the rest of program? One error in one module shouldn't prevent huge suite from compiling.
• cheery 13y ago
  Quick fix can be permanent fix. Those adjectives do not exclude each other out. I think this article's biggest problem is that he's using running phrases too much, that are correct but without meaning: "If you skip work, you have to work more later" Obviously. Also anything can be taken as art, even things not made by human! "Think of programming as an art". What does he mean?
  • chc 13y ago
    This is your fifth top-level reply. It becomes a bit overwhelming when one person is the entire comment screen. Please, in the future, collect your thoughts and put them into one comment.
    • pkroll 13y ago
      Isn't there something to be said for splitting up the comments, so you don't get a single thread that covers five different points and nests forever?
      • chc 13y ago
        No, I don't think there is. They are all still broadly on the same topic. Imagine if I made each sentence here a separate reply. I mean, they are separate sentences and could conceivably be responded to individually, but it would still be pretty silly, wouldn't it? The only case I can see for doing multiple sibling comments is if you have several truly unrelated thoughts that each deserve a deep treatment. But that's not what's going on here. As cheery noted elsewhere, he/she simply didn't know you could edit comments.
• rhapsodyv 13y ago
  + Trial and Error The most common error that I see is the programmer trying to make the code works, or trying to fix the error, using trail and error, instead of understanding the problem and make a better solution.
  • pjungwir 13y ago
    That's just what I wanted to say. I call it "debugging by superstition." I think there's a fine line between this and a useful hunch, but there is a difference. Superstitious debugging is rapid-fire, change-a-line-and-try-again. A hunch extrapolates from the evidence and your experience, and it leads to an experiment to prove or disprove it. In the sysadmin world, Rachel by the Bay has some great stories about following hunches.
• gailees 13y ago
  Meh. #hackermindsetFTW
• d23 13y ago
  OP should bold the headers. If he doesn't understand how to make an article readable, it makes me question whether he understands how to make code readable. Anyway, the fact that he thinks these need to be stated is interesting in and of itself. Points 1-3 just come down to judgement that you develop as your career progresses. You start to know when a problem should be googled, when a library is necessary, or when something should be rolled on your own. There's no way to feel this in your bones without practicing and running into what it feels like when it's been violated. Making quick fixes vs. permanent ones should be dictated by how corner-case the fix is and the time that would be consumed to make an abstraction to handle it cleanly. It's about striking a balance between over and under engineering. Again, this comes down to judgement and experience. It's seemingly easy to understand this on an intellectual level. Getting on an experiential level is another thing altogether. Ignoring warnings is an obvious no-no.