Topics

1

Developer's Corner / What Every Computer Scientist Should Know About Variables

« on: August 15, 2006, 12:18 PM »

i'm sure many of you think this is an obvious story, but i'm going to tell it anyway for all who didn't know yet :-p


there are 2 types of variables in programming, one is called a value type the other is called a reference type. very nice that you have them both, but what does it actually mean? well, a value tpye variable is actually quite easy to explain, it's just a variable that can hold a value. then the question comes, what is a reference type variable then? well a reference type variable is a variable that has a value (of course) and also a reference to itself.

now the reason why we need 2 types of variables becomes clearer when you understand what happend when a variable is passed to a method or function.

lets look at the normal situation first:
when you pass a value type variable to a method, the actual value of the variable is copied into the function. so the function gets a new copy of the value to work with. this means that if you change the value of the variable inside your method, the origional value of the variable outside your method is not changed at all.
when you pass a reference type variabel to a method, the reference to the variable is copied into the function. so the function gets a new copy of the reference, but not of the value. this means that if you change the value of the variable inside your method, the origional value of the variable outside your method is changed.

now you can also pass variables "by value" or "by reference" in some languages. usualy this mean that reference type variables are always passed by reference, even if you declare the method to pass "by value".
for a value types it means that a reference can be created on the fly when you pass the variable "by reference"

now there is one more tricky thing about all this reference and value business, if you want to know if changing your variable inside a method will change it outside the method too then you need to know about something we call "immutable variables" too (yes i swear we are done after this one). basically when a variable is immutable it means that it can not change. of course it's not the same as a constant though, because you can make a new copy of this type of variable and change the reference to point to this new copy. this way it looks like your variable changed, and it also looks like other references (that did not get updated) still have the old variable value (in fact they have the complete old unchanged variable).

phewww, i bet some of you need to read that 2 times :-P


so now some ways these are all used
value type: usually has small data (like numbers) and can not be NULL, stucts/stuctures
reference type: usually has lots of data (like strings), classes
immutable: usually normal reference type variables

not in all languages this is the same though, just in most. C for instance has the char type which is basically a string like type, it is not immutable however (this is one of the reasons why C is called a low level language by some)

2

Developer's Corner / What Every Computer Scientist Should Know About Error Handling

« on: August 14, 2006, 12:59 PM »

Error handling assumes there are errors in your code, this is of course a bad assumption and all time spend to making error handling should be spend to error checking instead, well this is my view at least.

why do i make such a wild claim that error handling is not a good thing?
well in my oppinion there are 3 types of errors:
1 unforeseeable and unrecoverable errors, in this grou you would have for instance the "out of memory" exceptions. well what can you do if this happens? not much actually, most likely you don't have the memory to do any recovery to begin with.

2 errors that function as output of an function, in this group you would have an "read only" exception on an file operation. the exception is thrown as kinf of a return value/status. this kind of errors should be handled, but can be argueed to be more like status messages or return values and would always be mentioned in documentation.

3 foreseeable erros, in this group you would have errors like "divide by zero" or "null reference" exceptions. basically instead of of trying to catch them later on it's better to check for these to go happen up front. if you forget to write the check and handle things properly before doing an divide it is better to not try to recover this later on. trying to recover would only make it easier for the bug to slip through your tests and checks and for the automatic recovery to make your program behave odd.

of course you should handle errors somewhere (on the highest level for instance) to output them to a log or display them on the screen instead of letting the code really crash. the point is though, don't write to much error handling! (like in every function or method) it's one of the biggest mistakes you can make in getting bug free code (i know it sounds odd, but try it sometime)

3

Developer's Corner / What Every Computer Scientist Should Know About Units of Measurement

« on: August 14, 2006, 12:03 PM »

While developing some code at work i decided to write a class called Unit that would handle all translations between units of measurement. from seconds to minutes, meters to kilometers, bytes to bits, etc. a nobel task to ease the burdon of other developers in the team and to reduce errors in their code. so i started and made my class, and after finishing it i debugged it of course

now, end of story right ...    nope!!!


after writing a pricing engine for a new satallite system i found out it was impossible to use my class and get correct results! i kept debugging and debugging, and after having debugged the unit class several times i decided to take a real close look at it and super debug it once more.

so now we have the end of the story right?   ... nope...

yet again the super debugged unit class was giving trouble and it took me a whole night of stepping and debugging to realize something trivial. units word really odd! there are units that translate as follows:

1 minute = 60 seconds (this makes the factor 60 and we need to multiply to get from minutes to seconds)

then we also have:
60 calls per minute = 1 call per second (this makes again the factor 60, but instead of multiplying to get from minutes to seconds we need to divide this time!)

it turned out that all my troubles came from forgetting that unit per unit translates diffrent then a unit by itself!


the moral: you can make a reusable class for "Units of Measurement" and to translate them into eachother, but don't forget that there are 2 types of translations!

4

Developer's Corner / What Every Computer Scientist Should Know About Time

« on: August 14, 2006, 11:44 AM »

time is a weird thing on the computer, in real life time is already weird since there is a future and a history. but in reality there only is a now.

well on the computer it will get a lot weirder. on a computer time is not synchonious, especially with networked computers and time synchronization the time can go from a moment in time to a moment in time before. so a computer can travel back in time! then later on it can travel forward in time again. especially with software that records history or the moment some things were recorded this can have huge implications!

for instance: imagine a log mechanism that records when an action is done, then the user can look in the log to read back if they did something or not or if the computer recorded the action and performed it correct. well if you display the log sorted on the date/time you recorded the action at, then it might be that (say if a clock chip failed) the last entries are sorted all the way to the beginning of the log. now the user checks if the action they did is performed correct and they see nothing is done at all (because it is not at the end of the log but at the beginning).

well, this seems a small problem but i can tell you that at my company (mobile satellite phone business) we could cause a lot of trouble this way. a user could accidentally added too much credit to their satallite phone with all the trouble that comes with that, angry customer, phones going over their usage limits, billing diputes, etc.

the moral of the story, never forget that time in not synchronious in a computer and that dates and times are never to be trusted fully!