- Code correctness is often
an overlooked item
and now that you have some experience writing code,
it's a very good time to talk about it.
Let's see first what we mean by that.
There are several measures that you can take
to insure that your code is written correctly
namely that it does exactly what is suppose to do.
First of all, you should look at your initialization.
When you declare a variable,
is it obvious that the value that that variable has
by default is the one that you need
or is there any danger that an initialization
may cause a variable to have an unknown value.
This applies to arrays, variables and constants.
Another type of measures are qualitative.
For example, has the problem been properly defined?
Are you sure that are you addressing the right problem?
Planning, did you take time
to think about your solution
to come up with the right idea for implementation?
Do you have all the resources?
Do you have enough knowledge of the programming language
or of the algorithm or of the problem space
that will allow you to even start thinking about the problem
let alone planning the solution.
Precoding, never just start coding.
The more you plan, the more you think,
the more you run ideas in your head,
the better your code will be.
It is very hard psychologically
once you start writing the code to stop
and go back to paper because you have that illusion
that you already invested so much in it
and it's a shame to let go.
Do not let yourself to get to that point.
Plan well before
and even if you feel at some point
that you prematurely studied to code,
it is perfectly fine to drop everything,
go back to the drawing board and start over.
Second is your style of programming.
Are you documenting?
Are you using variable names correctly?
Are you indenting your code so it's easy to read
and so on?
The other one is verification.
You can place measures in place in your code
that will give you a lot of feedback
and we'll see that shortly.
This program example,
impart shows a few things when we run it
and the others are again in the same category
of tips, advice.
Let's look at the quantitative measures.
The quantitative measures are simple,
at the level we are discussing here
and refers to primarily to initialization.
Let's look at lines 18 through 21
where I am declaring four variables.
An int array numbers of length 100,
an array of char also length 100,
float distance and longDistance
and none of them is initialized.
Let's test, let's print the values,
for example on line 26, numbers 28,
word 28, distance and longDistance.
Let's see what does C decide to place
as a value into a variable if the programmer
has not explicitly assigned a value.
The best way to do that is simply run the code.
58 has the value of zero even though
I haven't put anything in there.
Word 58 has nothing, so apparently C thinks that
nothing for characters is the equivalent
to zero for numbers.
Distance and long distance are zero
so you can see a pattern here
that whenever you declare a variable
and you have not initialized it to a particular value,
its default value is zero.
If at some point in your code you are dividing
by that variable and you forgot to initialize it,
you might crash your code because you're dividing by zero.
Doesn't mean you have to initialize it to one
or something else.
Only initialize it to something that makes sense.
Let's look at some of the qualitative measures
that I am suggesting.
Again those are not recipes or prescriptions
but our points for you to think about, contemplate
and ultimately decide for you
what makes sense for you and in your program.
For example, is the problem you are trying to solve
in code been clearly stated and defined?
How do you know?
If you checked with other similar project,
maybe somebody has already tried to solve the same thing
and they reach the conclusion that the problem is unsolvable
or the approach they took and you are repeating
it's not very efficient.
Two, think, have a plan, develop an algorithm,
draw a flowchart.
Only then start writing code.
Make code writing your last priority.
Debug algorithms on paper, what does it mean?
Maybe you want to create a table of numbers
and you pretend that you are the computer,
plug in the numbers in loops, in variables
and see if you can track what the program would do
if it run for real.
Then think without testing but just try to imagine
and find potentially pulling your code.
Let's say you wrote an array that can process
a thousand numbers and your program is built
on the assumption that at any given time
they will be about a thousand numbers.
What happens if all of a sudden that number
is a million?
Is your code going to run as efficient for 1,000 numbers,
as for a million numbers?
Should you even worry?
Maybe this is such an esoteric hypothetical situation
that it's completely not applicable to their situation
but you should at least ask yourself this question.
What if you get the very small data sets?
What if it's only two numbers
and you expect a thousand?
Is your arrays and everything you define,
are they overkill?
What if there's no data?
The program starts to run and nothing happens,
it's expecting to read some data from a file
but the file is empty, will it crash?
Will it give you a message or will it hang,
will it just get into an infinite loop
until some data is available?
What if you give it very large numbers
so your program is programmed to deal with numbers,
let's say between negative 1,000 and positive 1,000
and all of a sudden I give it a billion?
Will it be able, if your number is going to start a loop
and you know that the number is typically
is going to be 30, 40, 50,
all of a sudden you give it 10,000.
You might think the program doesn't work
because everything is so slow,
it has to finish the loop.
What if you give the number that are very small,
what about 0.0000001?
Will something like this be rounded to zero
and crash the program if you divide by it?
All these issues you have to think about
at least on paper and then start to experiment
with writing the code.
Simpler is better than smart.
Simple means easy to debug, easy to improve,
easy to explain, easy to give to someone else.
Do not always attempt to show how smart you are
and how efficient your code is
and how you're better than anybody else
and your codes does trick that nobody understands, only you.
It's gonna come back to hunt you if not bite you.
Keep it simple, keep it easy
and you will be happy and your manager will be happy
and everybody in your team will be happy.
Verify the code as you go.
Do not write the whole thing and then test,
you wrote a function, run it right away.
You wrote another function,
maybe the function start connected,
run them together.
Organize the code into very small functions
so you never have a very very long function to test.
Again, those are just some tips.
Maybe you have a function again, initialize values,
we saw a couple of videos ago,
you can initialize by passing pointers by reference.
You have a lot of option to this point,
I cannot stress this too much.
Think then code.