Basic Program Logic and good programming practices.

[zepherin]

This tutorial comes in because I'm tired of debugging code that looks like crap. Most of this tutorial will be writen in pseudocode or C++ or java (which is similar), whatever just comes out.

Problem solving:
Before you start programming you need to have an idea of what you are going to do that means you don't just bang out code, you waste a lot of time fixing logic and syntax errors that way, take a look at it figure it out if it's a math problem write out the function and how you want it to look do a flow chart or use some pseudocode so when you finally put it into your programming language of choice it looks clean and well thought out. This is one of the most over looked steps in programming and it results in some ugly looking code with lot's of parts that don't need to be there. If you have it figured out before you start codeing it really goes a lot faster.
Example: so if you have a problem that requires you to count how many A's you got in a class this year and determine the A by percent. make sure you work it out before hand it doesn't have to be nice you could just jot this down (granted it's a bit simplistic but it's much more effective on really complicated problems like the towers of henoi [try doing that one without any help or jotting it down in advance] has a simple and elegent solution but it takes some reasoning out).
if (grade > 90)
counterA = ++counterA;
These kind of things make it easyer for you to put it down.

Programming structures:
Back in the day programming was done by telling the program to hop to different lines after that line was completed and resulted in some really confusing stuff to look at, hard to debug too because you weren't sure what was going to be effected by it. Now there are three types of structures.
Sequencial: Top to bottum left to right 1 after another.
Selection: choices dependent on user imput if statements almost anything involveing booleans go here.
Repetion: repeats using for while do/while statements, I'm a while statement fan myself because it's easyer to understand it at first look, but some people like to use for's.

Basics of programming
Ego notice it at the top, this is very important put as much info as you can including the book your using for programming your name (psudoname if your uncomfortable with your real name), the progam name, what the program is suppose to do [if anything put that one down folks], and cite the sources of code you actually lifted into your program and mabey an original program if your modifying open source.
Use remarks but don't over use remarks, here are times to definatly use remarks
When you introduce a new variable ( make sure you tell what the variable does)
For each part of the actual program ( for each function not each line but like //this part counts the grades. or //this part sorts the array.)
When you do something that is generally a confusing step or a few lines that are garbled but compile and work.
Variables are your friend, but don't use more variables than you need too, use as many local (variables that only work in a certain part of the code) variables as you possibly can it cuts down on debugging time because you only have worry about certain sections being broke.
Moduals, use moduals, a lot of programming is debugging and fixing, make sure that you have your program sectioned in an easy way with small chunks of code so it doesn't look like one emense programs, your buddy might not tell you to get lost when you asking him to help debug your program if it's seperated nicely.
Use tabs and spaces, (I'm guilty of forgetting this one here) use tabs and spaces to set aside selection and repetition structures and ANYTHING nested. This is important so the code is pleaseing to look at and also helps organize carage returns and the like.
And lastly start small. Take a small chunk of code and make sure it works first don't program the whole thing and hope it compiles. If the code has a bunch of sections that do similar things only write one of those things compile and debug that part of it then adapt it to other parts of the program. If one section works the rest of it has a good chance of working too.

to leave you I'll drop a bit of code that I consider from good programming practice this will be in java.
//zepherin
//antionline teaching text
//www.antionline.com
//cosmos thread
//zephprog.java
//display a simple text message
//Java Software Solutions 2nd ed. by John Lewis and William Loftus

public class zephprog //these statements are just the name of the program and setup the main statement area
{
public static void main (String [] args)
{
int x = 21; //this variable just holds the place 21 it could be used as anything
System.out.println ("I am a piece of text what is your name:");

}
}
hoped you liked my little tutorial

[ammo]

hum..
"counterA = ++counterA; " ?
that would be pointlessly redundant... you probably meant:
"counterA++;" by itself.

and using spaces and tabs is called "indentation".

Besides that, you bring up good points.

I myself have done a good bit of debugging friends programs in college, and it's such a pain when its poorly written. These weren't even very big programs, but just complex enough to be easily messed up. I mean, I (we, when in teams) had the same programs to do and sometimes, reading friends code, you would think your not even working on the same assignment! ::

One thing I like to stress is code modularity (like you mentionned):
Use fonctions/methodes. One function/methode should do a single thing, and do it well.

Also, stick to your organisation's coding standard. If you don't have one, you might want to consider making one. It makes reading co-workers' code soooo much easier!

Ammo


PS: Heh, this makes me think it's been a quite a while since I have written significant code... I just realized I miss it...

[er0k]

good tutorial for people who already know how to write programs ... but not for newbies. No offense. Cause i like ya zepherin