Programming Mistakes

http://www.singhrahul.com/2013/07/5-programming-mistakes-you-should-stop.html

by rs_ • 13 years ago

40 31 13 years ago

lucisferre• 13 years ago

I'd argue these are examples of bad habits rather than outright mistakes (and yes, there is a difference).

"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.

cheery6• 13 years 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!

tlongren2• 13 years ago

I stopped reading at "more better".

vowelless• 13 years ago

You're penalizing a non-native English speaker for minor English grammatical problems? Why not offer to help him instead?

tlongren2• 13 years ago

I didn't penalize him. I just couldn't read past there. I actually upvoted him. lol.

chc3• 13 years ago

I stopped reading at "I stopped reading," because what follows is pretty much never insightful.

cheery6• 13 years 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• 13 years ago

Using a library is just one giant copy/paste, right?

touristtam• 13 years ago

ok, but this wall of text is not very nicely formatted.

mataug• 13 years 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• 13 years ago

Or used a non link baity title.

danso• 13 years 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• 13 years 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.

d232• 13 years ago

And I would say "searching for a fix on Google" is almost always the first thing a beginner should do.

I agree in the sense that the problem is that a beginning won't know what to Google, and there's not a thing that will teach them that other than trying it a bunch of times and hoping they have the brain to learn what will turn up results and what won't without having to do it.

It's the difference between googling "ajax photocropping service python" and understanding that what you really need are 1) a library to show a simple cropping interface in javascript 2) a way to crop images in python and 3) a way to receive ajax requests and handle them.

cheery6• 13 years 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• 13 years ago

Why have you made 3 posts on this thread?

cheery6• 13 years 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.

sonabinu• 13 years ago

I think the one about googling before trying is so true!

hvs• 13 years ago

Please review the submission guidelines for HN:

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_• 13 years 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 :)

cheery6• 13 years 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.

cheery6• 13 years 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?

chc3• 13 years 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• 13 years 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?

rhapsodyv• 13 years 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• 13 years 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• 13 years ago

Meh. #hackermindsetFTW

d232• 13 years 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.

Programming Mistakes

Related Stories