How to know what code to write?

[legoge]

I am brand new at Visual Basic 2008 (and programming in general) and am taking an online IT course. I do not understand Visual Basic and do not know how to determine what code to write in a given situation. How do you determine what code to write?

[crazyhorse09]

Go to college and take a class, or read a book, or take "an online IT course"... lol.

[Xetwnk]

First, familiarize yourself a bit more with Visual Basic itself: what statements exist? What do they each do, individually? You will find that they can be grouped together into various categories: some statements have to do with declaring variables; some manipulate data (such as assigning a value to a variable); some modify the flow of execution (e.g. instead of proceeding straight from top to bottom, doing each statement just once, you can make portions of the program execute repeatedly (or "loop") until some set of conditions is met, or can cause the program "branch" -- that is, to take a different "path" through its code -- depending on some set of conditions, etc.); some are used primarily for their "side effects," such as printing, displaying, etc. There may be other categories; I am writing "off the top of my head."

It is also important to write and punctuate all statements correctly: the computer will do what you TELL it, NOT what you MEANT TO tell it! :-)

Next, think about the program you want to create. What do you want it to do, EXACTLY? Think it through in as much detail as you can, including internal operations (e.g. math), side effects (printing, displaying), and flow of control (repeats and branches). Think in big chunks first, then break those down into smaller chunks, and those into even smaller chunks. Keep at it and eventually you will find it possible to express each chunk in a statement (or a few statements) of actual Visual Basic.

You might find it useful to draw diagrams; there are a lot of software tools for this, but it's actually easier, at first, to just draw them on paper or a whiteboard -- one less software tool you have to master while you're trying to concentrate on something else. (I don't know if they still teach new programmers "flowcharting" anymore; a pity, it is a very useful technique/tool; Google for "flowchart" and you might find something interesting/useful). Some people also find it useful to write "pseudocode," which is basically the steps of your progam, in general terms, in plain English (or whatever you speak).

You can actually do the flowchart / pseudocode before you know the language very well. As an example, I don't know Visual Basic well myself, but if I wanted to write a program to "print out my name ten times," I could at least begin it, by writing pseudocode such as:

Do ten times:
   {
       print my name -- "Xetwnk"
   }

That's a combination of English and stuff I've used in various other programming languages; it doesn't matter as long as YOU (and anybody else you want to discuss it with) know what it means.

THEN I would go look more closely at Visual Basic itself and find out "okay, how do I tell it to do these things?" I would want to find out what "looping" statements are available for the "do ten times" part, and I would want to find out how to "print my name" for the printing part. I would keep my eyes out for whether or not I needed something like the braces ( { and } ) shown here, in order to begin-and-end a "block" of code for the loop to operate on. When I had a pretty good idea what to write, I would type it into Visual Basic and try to run it. If it worked, hooray, I'd be done! If not, I would assume Visual Basic would give some error messages that would suggest where I'd gone wrong.

In a program this simple, and with my current severe shortage of Visual Basic knowledge, most likely I would have syntax errors: would have mis-punctuated one of the statements. "Oh, I was thinking of Atari BASIC (from 1980!) where the "for" statement was punctuated differently..." etc.

It might turn out that my problem was of a different order: the printing statement might fail because I might, say, have neglected to create a window within which printing can occur (I have no idea whether that's really needed in Visual Basic, but my experience with other languages and environments suggests it as a strong possibility. Some things just come with experience, so be patient.)

At first you might have no idea what the problem was, and would have to start from the wording of whatever error message(s) you got. Turn to the Visual Basic help text, online help, or as a last resort forums such as this, looking for mention of whatever solid words appear in the error message-- maybe it says "can't PRINT to null WINDOW" or something-- and/or the program statements appearing using in the line where the error occurred. "No output window" would be pretty clear; something more cryptic at the line containing the print statement might be somewhat less clear. In the first case, you would have to think about what a window had to do with it, and hopefully eventually realize that, "oh yeah! Everything in Windows has to appear IN a window, and I didn't create one!" So you'd start looking for information about creating windows. In the second case you'd have to start by reading up on the print statement in more detail, and maybe there'd be some mention, there, about having to print "to a window," which would hopefully lead you to the same conclusion.

Worst case, you have no idea what's wrong and have to just start flipping through the help index, the Web, these forums, etc., looking for anything that seems relevant. Ask questions if, where, and as you can. (The trick in asking others is to be as specific as you can: instead of "my program doesn't work," you'd want to say, "I am getting a ____ error at line ___, which is the print statement." Supply an example of code that exhibits the problem. Keep it short. This, too, comes with experience.) In order to fix a mysterious problem, first you have to diagnose it, and that can be tricky and tedious -- but can also teach you an enormous amount of useful stuff!

Over all, take heart: it's probably NOT JUST YOU. It can be daunting to learn a new language and platform no matter HOW experienced a programmer you are. I can't tell you, for instance, how long it took me to first get started with Visual C++ and MFC, ten years ago, when I had "only" ten years' professional programming experience on OTHER platforms -- because it turned out Microsoft's documentation was all written for an audience who had some prior Windows programming experience, which I didn't. It took me several weeks of puttering around before I realized -- for one example -- that a "window," a "window handle," and a "CWnd" were three slightly different, but related, things, and could not be used interchangeably... except that CWnd provided functions that made it LOOK LIKE you COULD under certain circumstances...! I had a lot of headaches those weeks. ;-) Unfortunately, this sort of thing is going to crop up fairly quickly whenever you try to get started doing any kind of useful programming in any new environment, particularly any GUI-based environment, which is to say any computer you've ever sat down and used by means of a screen, keyboard, and mouse. (Frankly this stuff was easier twenty years ago when you had a black-and-white, text-only display, and a keyboard-- PERIOD. You didn't have to learn a complicated GUI architecture at the same time as you were trying to master the rudiments of just plain PROGRAMMING.) You'll want to read the sections of Help text that deal with the overall Windows environment -- which, judging from Visual C++ ten years ago, might be kind of hard to find among the heaps of more-advanced topics. When you've started to make some headway and become somewhat familiar with the Windows way of doing things, how the pieces fit together, etc., you might find it helpful to read about those topics in the help for OTHER Windows languages and programming tools, if you can... the C# manual, say, may mention a detail, or use a particular turn of phrase, that suddenly makes something snap into focus that wasn't clear in the VB texts.

Hope this helps. Best of luck to you!