- Now that we discussed what functions are, we can
proceed with our topic of functional programming.
Functional programming is essentially writing
a program that, well, consists of functions.
We chart tasks and subtasks.
So let's refine the thought.
A top-down design approach breaks down
programming to smaller functions.
Meaning, you first take the big problem at hand,
you're breaking into smaller problems, and you
tackle each one of them individually.
This way, a big project becomes much more manageable.
This is true not just for computer programming
or computer science, but especially
true for computer programming.
Smaller pieces of code, smaller functions,
partial code, loops and other constructs
are easier to decode and debug if
they can be isolated and tested.
The code becomes easier to maintain,
easier to make changes.
Not just by you, but other members of your team.
Let's continue with our previous example
and refine this a little bit further.
As you can see, when we look at a code,
we should see a clear description of every section.
For example, we have global variables, in which
I define some dummy array that doesn't do anything.
It's just an example that this is
where i would define a global variable.
Then we have our function prototypes.
Then the same name where all the functions that
represent steps toward the solutions are being called.
I give an example here.
This function is working except
I did not include a data file with it.
I just show an example in line 48,
which you saw in other videos,
how we can read data from a file.
This is an example of what a read data function should do.
It's simply a loop that gets the data and sets
it up into a variable for later processing.
So in the second refinement step,
after we set up the skeleton, we can now write
for every function, a little bit of a text.
What do we think this function should do?
For example, if you want to validate the data,
you could check things like,
are the numbers within a plausible range?
So you look at the data that your code generates,
and you ask yourself, is this plausible?
Does it make sense?
Is this the same data that someone that was
a professional in the field, or a professional
in your company, or a manager, or anybody that
has experience in the field, would think,
yes this is consistent with findings over a period of time.
You can also check your structural integrity of your code.
For example, have you missed any array elements?
You could run some print functions that will
give you the content of arrays, of variable,
of strat fields, and so on.
Are there any variables that haven't
been initialized, and so on?
We'll proceed then with process data,
in which you would identify formulas,
formats and standards that are compatible
with the problem you're trying to address.
Analyze results.
What type of graph, tables or lists do you need?
Whatever else that's customary to your organization
was required by your program to produce?
When you look at the data and analyze the results,
especially through a statistical analysis lense,
is there anything that stands out
as being out of the ordinary?
Out of the ordinary could be, yes that's great,
we have low sales.
Now I find some evidence of great sales.
But it could also indicate some errors.
Finally, you might have to generate a report.
You should know what type of reports
are expected from you.
Anything that is compliance related.
Formatting.
Archiving.
Does your program store data in more than one
location so you can refer to it later?
Maybe due to regulatory issues or
maybe just because you need to have a backup.
How about sharing your results with others?
Does your program include the mechanism for storing
data onto a shared folder onto a network.
Is it secure?
Every project has it's own requirements and issues.
This is just an example.
It doesn't mean that every program you write
will have validate and test and
generate reports and analysis,
but this is a good example of how
it might look like if it should.