I am in a beginning class to VB.Net. I know the basis and formulas of the code but I'm having problems figuring out the best way to approach coding the application. I'm particularly having trouble with coding functions and procedures (not event procedures) effectively. I have spent close to 14 hours working on an assignment trying to figure it out.
Any help would be hot.What is the best way when figuring out best way to approach coding a VB application?
You should probably realize that your question is extremly relevent to the indivudal asked. Personally, I don't believe there IS a ';best'; way, as with algorthim design, just because your solution is considered the best by today's standard, that does not mean it wont be obsolete by future standards.
There are many books dedicated to problem solving in computer science, not just creation and implemneation of algorthims.
Anyway, the technique I use goes something like this.
Read the program description
Read the program description again
Read the program description again
Make sure I understand the program description
Get all required documents for program creation, testing, input/output
Design an algorthim or test the one in use.
Use sample input to get ';good'; output
Test for possible bugs by thinking about the impelmentation.
Code program
Test Program
Debug program
If all other steps are completed, document program.What is the best way when figuring out best way to approach coding a VB application?
I'm not sure what kind of foundational classes you've take prior to taking your current class, but there are some programming principles that are common for any object oriented language. That is to modularize the code into reusable classes that can be called upon in the future.
So, as someone else explained, when you are reading through the project requirements keep in mind what kind of code would be needed to accomplish this task. Keep the methods and functions of the classes relatively short. Try to keep the lines of code for each method and function between 10 - 20. If you start getting more lines of code than that, you may want to think about refactoring your code. That is, break the procedure down into two procedures.
For instance, if you were needing to return a dataset from a database for the students who took biology this last semester, you could write a function that would:
-take criteria from calling method
-construct a query with the criteria
-connect to the database
-query the database
-load results into dataset
-return the dataset
That would work fine, but we could go even further and break this down into two functions:
-one function would be to collect the criteria from calling method
-create a query or stored procedure (command object) and pass that information to another function.
The second function would:
-take the command object from the calling method
-connect to the database and query the database using the information provided
-return the dataset to the calling method
Now, you have a generic method that can be used simply to connect to the database and query the database using any command object
You won't have to rewrite that code again in the future.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment