Consensus on programming techniques

[b][red]This message was edited by shaolin007 at 2003-10-3 6:42:25[/red][/b][hr]
Just a simple question for the people out there, and that is the style in which you out line your programs logical progression? Do you prefer using pseudo code, and why? Or some other method? Please explain. Thanks for your response.


Comments

  • : Just a simple question for the people out there, and that is the style in which you out line your programs logical progression? Do you prefer using pseudo code, and why? Or some other method? Please explain. Thanks for your response.

    [green]
    I'm no pro, but I write the help file first, hahahahaha
    Yep, a short rough draft, what the program does, and how to get it to work helps organize my thoughts.
    Help should be right up front, as the first thing the user sees, in a can't miss it file.
    1README.TXT sits at the top of the alph organized directory.
    Or help at the head of the executable so a viewer can see it,
    or running the program with out input displays usable help that humans can understand.
    A user only gives a program a brief shot,
    if the programmer isn't smart enough to give simple help in a non hidden file.
    I delete the program cause I know the rest of the program is going to be the same way. Low IQ, unusable and I'll probably know his favorite color before I know what the program does.
    I don't run any program unless I know what it is suspose to do first.
    AND the first thing you need to know to run a program is how to stop it.

    Once a quickie help draft is done, I know what program I'm writing.
    Writing a help draft helps organize my thoughts and a plan.
    Then a few lines in the .ASM file where I'm going to write code in my blank template.asm is the pseudo code programmers outline.
    Each line starts with a comment and describes a goal.
    Then as you write the program, you use the pseudo code as a discriptor comment line before a code group.

    ;get cmnd line input & parce Fnames
    ;FOPENR F1 exit if fail, FOPENR F2 exit if it opens, FCREATE F2
    ;load F1 to Vmode3 mem 0xB900 page 1-7, process into CS:BUFFER LOOP
    ;FWRITE OUTfile, Fclose all, exit

    This pseudo quickie is an outline, & the comments too.
    A space inbetween each code group, seperates them,
    do enough commenting that you can come back into the program later
    and do easy maintenance without haveing to relearn it's lay out.

    Knowing what you want to write is the hard part. (writing your help file helps)
    Having a plan of action is a good start. (the pseudo code comments serves two purposes)
    Lots of backups. (back up the whole directory at once. When the program works & your done, delete the old back ups.)

    I suspose that junk wasn't what you were looking for,
    but I'm interested in your views/expierience too,
    and hopefully others will throw in their two cents also.

    Bitdog
    [/green]


  • : : Just a simple question for the people out there, and that is the style in which you out line your programs logical progression? Do you prefer using pseudo code, and why? Or some other method? Please explain. Thanks for your response.
    :
    : [green]
    : I'm no pro, but I write the help file first, hahahahaha
    : Yep, a short rough draft, what the program does, and how to get it to work helps organize my thoughts.
    : Help should be right up front, as the first thing the user sees, in a can't miss it file.
    : 1README.TXT sits at the top of the alph organized directory.
    : Or help at the head of the executable so a viewer can see it,
    : or running the program with out input displays usable help that humans can understand.
    : A user only gives a program a brief shot,
    : if the programmer isn't smart enough to give simple help in a non hidden file.
    : I delete the program cause I know the rest of the program is going to be the same way. Low IQ, unusable and I'll probably know his favorite color before I know what the program does.
    : I don't run any program unless I know what it is suspose to do first.
    : AND the first thing you need to know to run a program is how to stop it.
    :
    : Once a quickie help draft is done, I know what program I'm writing.
    : Writing a help draft helps organize my thoughts and a plan.
    : Then a few lines in the .ASM file where I'm going to write code in my blank template.asm is the pseudo code programmers outline.
    : Each line starts with a comment and describes a goal.
    : Then as you write the program, you use the pseudo code as a discriptor comment line before a code group.
    :
    : ;get cmnd line input & parce Fnames
    : ;FOPENR F1 exit if fail, FOPENR F2 exit if it opens, FCREATE F2
    : ;load F1 to Vmode3 mem 0xB900 page 1-7, process into CS:BUFFER LOOP
    : ;FWRITE OUTfile, Fclose all, exit
    :
    : This pseudo quickie is an outline, & the comments too.
    : A space inbetween each code group, seperates them,
    : do enough commenting that you can come back into the program later
    : and do easy maintenance without haveing to relearn it's lay out.
    :
    : Knowing what you want to write is the hard part. (writing your help file helps)
    : Having a plan of action is a good start. (the pseudo code comments serves two purposes)
    : Lots of backups. (back up the whole directory at once. When the program works & your done, delete the old back ups.)
    :
    : I suspose that junk wasn't what you were looking for,
    : but I'm interested in your views/expierience too,
    : and hopefully others will throw in their two cents also.
    :
    : Bitdog
    : [/green]
    :
    :
    :
    [blue]I started using a little trick (stolen from M$ no doubt.) Say, I code something and can't finish right now, so I mark the spot with "TODO", like:
    [code]
    if (open_interface_to_some_object) {
    } else {
    // TODO: use other interface available...
    }
    [/code]
    When the time comes to clean up the project - I simply search all files for "TODO" and have my work cut out... can be used when coding in any language.
    [/blue]
  • : // TODO: use other interface available...
    [green]
    I'll bet your "TODO" also allows you to stick to a train of thought and finish it,
    then come back and do the details that would have made you/me/us
    loose our train of thought (overview).
    Maybe even dummy proc's could be written with a TODO comment describing in general what the proc should do.
    Then you could check the code by assembling it, and write the proc's second.
    (A dummy proc might be nothing more than a LABEL followed by a RET)

    Oh, never mind, ya got me thinking anyway.

    Bitdog
    Thankx
    [/green]


  • : : Just a simple question for the people out there, and that is the style in which you out line your programs logical progression? Do you prefer using pseudo code, and why? Or some other method? Please explain. Thanks for your response.
    :
    : [green]
    : I'm no pro, but I write the help file first, hahahahaha
    : Yep, a short rough draft, what the program does, and how to get it to work helps organize my thoughts.
    : Help should be right up front, as the first thing the user sees, in a can't miss it file.
    : 1README.TXT sits at the top of the alph organized directory.
    : Or help at the head of the executable so a viewer can see it,
    : or running the program with out input displays usable help that humans can understand.
    : A user only gives a program a brief shot,
    : if the programmer isn't smart enough to give simple help in a non hidden file.
    : I delete the program cause I know the rest of the program is going to be the same way. Low IQ, unusable and I'll probably know his favorite color before I know what the program does.
    : I don't run any program unless I know what it is suspose to do first.
    : AND the first thing you need to know to run a program is how to stop it.
    :
    : Once a quickie help draft is done, I know what program I'm writing.
    : Writing a help draft helps organize my thoughts and a plan.
    : Then a few lines in the .ASM file where I'm going to write code in my blank template.asm is the pseudo code programmers outline.
    : Each line starts with a comment and describes a goal.
    : Then as you write the program, you use the pseudo code as a discriptor comment line before a code group.
    :
    : ;get cmnd line input & parce Fnames
    : ;FOPENR F1 exit if fail, FOPENR F2 exit if it opens, FCREATE F2
    : ;load F1 to Vmode3 mem 0xB900 page 1-7, process into CS:BUFFER LOOP
    : ;FWRITE OUTfile, Fclose all, exit
    :
    : This pseudo quickie is an outline, & the comments too.
    : A space inbetween each code group, seperates them,
    : do enough commenting that you can come back into the program later
    : and do easy maintenance without haveing to relearn it's lay out.
    :
    : Knowing what you want to write is the hard part. (writing your help file helps)
    : Having a plan of action is a good start. (the pseudo code comments serves two purposes)
    : Lots of backups. (back up the whole directory at once. When the program works & your done, delete the old back ups.)
    :
    : I suspose that junk wasn't what you were looking for,
    : but I'm interested in your views/expierience too,
    : and hopefully others will throw in their two cents also.
    :
    : Bitdog
    : [/green]
    :
    :
    :

    I try and do about the same thing before I start to program. The problem I have with assembly so far is not the language but the fact that you have to break down the elements of your program into there smallest elements. Reading these computer science books I have are helping me understand that. The other higher languages like C have spoiled me since most of the lanuage is prewritten for you. All you have to do is pass the value's and off you go!
  • : : : Just a simple question for the people out there, and that is the style in which you out line your programs logical progression? Do you prefer using pseudo code, and why? Or some other method? Please explain. Thanks for your response.
    : :
    : : [green]
    : : I'm no pro, but I write the help file first, hahahahaha
    : : Yep, a short rough draft, what the program does, and how to get it to work helps organize my thoughts.
    : : Help should be right up front, as the first thing the user sees, in a can't miss it file.
    : : 1README.TXT sits at the top of the alph organized directory.
    : : Or help at the head of the executable so a viewer can see it,
    : : or running the program with out input displays usable help that humans can understand.
    : : A user only gives a program a brief shot,
    : : if the programmer isn't smart enough to give simple help in a non hidden file.
    : : I delete the program cause I know the rest of the program is going to be the same way. Low IQ, unusable and I'll probably know his favorite color before I know what the program does.
    : : I don't run any program unless I know what it is suspose to do first.
    : : AND the first thing you need to know to run a program is how to stop it.
    : :
    : : Once a quickie help draft is done, I know what program I'm writing.
    : : Writing a help draft helps organize my thoughts and a plan.
    : : Then a few lines in the .ASM file where I'm going to write code in my blank template.asm is the pseudo code programmers outline.
    : : Each line starts with a comment and describes a goal.
    : : Then as you write the program, you use the pseudo code as a discriptor comment line before a code group.
    : :
    : : ;get cmnd line input & parce Fnames
    : : ;FOPENR F1 exit if fail, FOPENR F2 exit if it opens, FCREATE F2
    : : ;load F1 to Vmode3 mem 0xB900 page 1-7, process into CS:BUFFER LOOP
    : : ;FWRITE OUTfile, Fclose all, exit
    : :
    : : This pseudo quickie is an outline, & the comments too.
    : : A space inbetween each code group, seperates them,
    : : do enough commenting that you can come back into the program later
    : : and do easy maintenance without haveing to relearn it's lay out.
    : :
    : : Knowing what you want to write is the hard part. (writing your help file helps)
    : : Having a plan of action is a good start. (the pseudo code comments serves two purposes)
    : : Lots of backups. (back up the whole directory at once. When the program works & your done, delete the old back ups.)
    : :
    : : I suspose that junk wasn't what you were looking for,
    : : but I'm interested in your views/expierience too,
    : : and hopefully others will throw in their two cents also.
    : :
    : : Bitdog
    : : [/green]
    : :
    : :
    : :
    :
    : I try and do about the same thing before I start to program. The problem I have with assembly so far is not the language but the fact that you have to break down the elements of your program into there smallest elements. Reading these computer science books I have are helping me understand that. The other higher languages like C have spoiled me since most of the lanuage is prewritten for you. All you have to do is pass the value's and off you go!
    :
    [blue]Well, that's exactly the problem with ASM - if we talking about the large projects (> 10,000 lines of ASM) - this kind of project can never be done fast enough in time to meet the needs of a software industry. By the time you code (and debug) all that - the product will be outdated. So, here is some kind of code reuse needed. I am currently designing the IDE for coding in ASM (Win32 only platform, DOS is gone... very little is done in DOS - I mean serious applications, not the learning stuff, like "Hello, World!", etc.) So, together with IDE I am planning to release the MFC-like library with object-oriented classes, so it is very easy to use these classes and you do not have to re-code stuff all the time. That is promises to be a nice IDE - with a different (non-standard) approach.[/blue]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories