|
SoCoder -> Blogs Home -> Blogs |
|
|
|
|
Mog
|
Redundancy - Good or Bad? |
|
I'm poking around at a small project- Won't give too much info on it since I want to roll it out in one impressive demo, but it involves using the internet to acquire media from the internet if the user doesn't have it. So i work out the functions. It builds a file list, checks to see if the files are on the harddisk, then spawns a thread to download each file- But i realized inside the download routine, i check again if the file exists before downloading it, and yet again afterwards. So it hits me. "Well that's redundant. Checking for it 3 times", and i move to delete it, but something else encourages me to keep it. I had a small dialog in my head, and it seemed to make sense that the more redundancy you have- the less bugs can pop out of the works just in case you forget some possible condition. So here's the question posed: If you can afford it, Is redundancy a good or bad thing? |
|
|
|
|
Comments |
|
| Friday, 25 December 2009, 14:34 | |
JL235
|
There are two sides to this. Typically redundancy aids code re-use. I can take one half of the code you described above, and I know it'll check if a file exists before it does it's stuff. As you say it also aids with error checking. The downside isn't really efficiency. For most sections of duplicate code in a project, the code is pretty cheap. The issue is the duplication itself which can lead to 'code drift'. What if you change the redundancy check itself? Then you will need to change it in three places. Plus often with duplicate code, each version will make indevidual changes and uses it's own implementation. So you will be maintaining three versions of the same code. Then if you mess up a change to one of those pieces of code, you've got a bug in one implementation (and not the other two). This makes it more confusing (because they are all meant to be the same). The best way of solving this is to try to move the redundancy checking code into it's own library or module. Your left with one section of redundancy code, not three. You'll still have some duplicate code (this is often unadvoidable). But by pushing the common code out this will be thinner, and so easier to maintain. This can also improve efficientcy. For example you could have a common file checking module that caches if the file is there or not. If you have three calls, only the first will touch the disk. The other two will just check your internal file list cache. |
| Friday, 25 December 2009, 14:52 | |
Jayenkai
|
Redundancy is silly, but double checking that things have indeed happened is a needed thing. For example, if, in Vista, I create the folder "Program Files/Test/", the program accepts that it happened. But it didn't, and a further check to see if the folder exists will tell me that it didn't. Nothing wrong with being certain that things are definitely happening the way you expect them to. .. And it's not as if you're doing it every frame!! 
|
| Saturday, 26 December 2009, 00:58 | |
spinal
|
Checking for required files, in my mind is a good thing. You can't just assume that if you downloaded it that it will be there. Nintendo made that mistake, so now people have a 1-in-1000ish chance of turning your Wii into an unusable brick (the latest wii update doesn't check if files a written properly before resetting the system).
|
| Saturday, 26 December 2009, 04:11 | |
Mog
|
All good points. I figured the structure of how it works is: 1) Initial:Quickly- What files do we need? Let's scan the server list and read CRCs to make sure nothing is corrupt. Ok, a few seem to be missing and a few are corrupt. 2) Deep Check: Are we sure the files aren't there / did they match CRCs? No? Let's download the right files. 3) After download: Ok, the download is complete, let's check integrity again to make sure everything is fine.
|
|
|
| |||
|
| ||||