reading code to write code better

Programmers look at other programmers’ code. That’s one of the points behind having the blog. This is a Good Thing because as someone who writes code, I learn from reading it. I am not alone.

What sometimes happens though is a coder will lift a snippet out. In most programming languages, with limited syntax, once someone has the best algorithm coded, there’s not a lot of room for improvement. While there may always be more than one Right Way to accomplish a task, there may only be one Best Way and once someone’s found it, it’s found forever (until someone finds An Even Better Way—which does sometimes happen, but very rarely).

So it makes sense to use a standard implementation of a known algorithm. It will look exactly like everyone else’s. These algorithms all have names though. Swap. Binary Search. Merge Sort. Whether you lift a merge sort from Joe Schmoe’s code or roll your own, it’ll be a merge sort. It would be 100% possible for you to create the exact same merge sort as Joe’s without ever seeing his.

On the other paw, if you have code that is the exact same as Joe’s for something else, then chances are it is Joe’s code and that is not only illegal, it is wrong.

There are all kinds of ethical reasons why this is a bad idea, but I’m not here to be your conscience. The number one practical reason it’s wrong is that if you didn’t write it, you do not deeply understand it, and if you don’t understand it, you cannot modify it or fix it if it breaks (or if it is already broken). Heck, if it’s broken and you don’t understand it, you won’t even know.

The number two practical reason is if you get caught, you could lose your job, or worse, your stuff (your bank account(s) are first, and then they sell your assets). You could go to jail. It has happened to other coders.

Now some code is okay to use, but it’s clearly marked with licenses (such as the GNU Public License) that specifically say so. If you’re in school, though, your class and school rules override any licenses. When in doubt, check with your instructor. If you’re working for someone else, your employer’s rules apply. Check with your boss if you have a question.

Study code. Read it. Learn to spot the good and the bad in it. Then use that knowledge to build your own solutions.

is it in there?

Sometimes you want to know if something is in a list. If the list isn’t sorted, the only way you can know for sure is to look at every item in the list and see if it is what you’re looking for. That is called a sequential search and it’s pretty easy to do. Since we’re using Snap, I’ll draw you a picture.

This script reports whether the item was found in the search or not, but it could be modified to do other things. Suppose for example, you have a list of students and you’re looking for all students named Bob. You don’t want it to simply stop with the first student. So you’d need to modify the search to change the “found” half of the or on the repeat until … and instead have found be a variable that you set to an empty list before the loop and then add the index positions as list items to it when you find a Bob in the class. If there is one. If there are no students named Bob, you would have an empty list, same as what you started with. If there were two students named Bob, you would have a list with two index positions in it, telling you where the name Bob appears in the list.

Of course there are other ways. This is programming and, generally speaking, you can find several valid solutions to any problem.

If the list is sorted, there are shortcuts. You can split the list and look in the part of the list where you know something is. You do this when you look through any alphabetized anything. You know not to look for something that starts with a  in the r section.