I usually handle the smaller utilites I make, but when I try to enlarge some idea I got,
I usually get so lost in the mess of my code, (even though I try divide it into some .inc-files) I almost get so
confused I by it I feel very uninspired to continue with it, because it kind of gets like a big mess....
(somewhat like this sentence LOL)

I'd like to hear about some strategies for making above small-sized programs from all you guru's hanging out here,
it'd help me out. Anything from coding to even like lifestile making stuff come true I would like hear about.

(dont know if this belongs to main or heap or not)
Posted on 2002-12-14 00:17:15 by david
I just dump all my codes into one file. haha... that's why I tend to hard to read c or c++ codes that spread into many files and stuffs like that. :grin:
Posted on 2002-12-14 02:15:22 by roticv
It is important to learn how to create an interface between one piece of code and another. The interface includes many things of which the most important is documentation. Even if the code is in one file complex interfaces may not be obvious without re-reading the whole file. I tend to create small files (1-4 pages) with minimal cohesion externally and high internal cohesion. This allows for me to make assumptions (generalizations) about large chunks of code and focus on the immediate function of the code in each file. Use the features of the langauge to abstract out objects. Your style and the program will determine where the code breaks apart.
Posted on 2002-12-14 02:58:19 by bitRAKE

There are a number of approaches when the project size is too big to handle as a simple file, you can start by grouping similar procedures in different files, file IO for example as this gives you some logical division.

You can look at the mechanical aspects of building library modules as this is useful when you have a lot of code complete that will not change. You can also build seperate modules and link them together. Some of these machanical aspects are handled in a test file in MASM32 called ALTBUILD.

Your program design will dictate what you have to do but it is worth thinking in large blocks and building them so they can be called from other blocks, much as Bitrake has indicated.

If you have the right disposition and can manage the coding style, there has been some work done on OOP style coding in assembler if that is what you are interested in doing.


Posted on 2002-12-14 03:10:29 by hutch--
Here's what I do:
Rule#1 for me is that ONLY one file in a project carries the .asm extension.
This is the file I will be compiling. All others are includes or libs etc.
I have a library of sourcecode.
Each time I write another project,I source some code from my library.
Each time I write another project, I select a few functions to add to my library.
I document my functions in the sourcecode, and I code new functions with a view to using them in future projects.
I like to have one ASM file that has a lot of include statements in it.
Modular approach to coding is good because the corporate world expects you to be able to work efficiently as a member of a team on a given project.
If you don't care about dollars, modular approach is still good because you can collaborate with peers if you are able to locate them...
Posted on 2002-12-14 07:17:55 by Homer
"What's your approach to large-style projects in asm?"

Rewrite in C/C++ :)
Posted on 2002-12-14 12:11:10 by death

I agree much with what bitRAKE and hutch said, but my experience forced me to extend these concepts beyond the simple program, and thus to extend them straight to the "OS".
I explain: if today I have to make e.g. a gfx editor, I won't make a gfx editor.. rather, I'll extend my OS / programming environment / language as much as possible with any code or interface of that gfx program that I may later reuse for any other program.. and then try to write a *VERY SMALL* gfx program application, which has nothing I can reuse for other programs, using the features of my newly extended OS.
For example, in a gfx program you may have blit routines, or gfx filters.. none of these shall ever go into the gfx "program", but as many as possible will have to extend my OS and eventually language, with benefit to any other future program (and sometimes even past one, when I do bugfixes or improvements to already existing modules).

You have to make a scientifical calculator program? Just reuse the RPN (Reverse Polish Notation, i.e. INFIX->POSTFIX) module you already wrote when you needed it for the compiler, etc..

For me reusability is a must, as well as extreme modularity and having clear and well designed/defined interfaces, as bitRAKE said.
It may seem boring, but defining a good and definitive interface is more important and critical than the actual coding.. at the end it lets you write better code, and in less total time.

I also focus much of my attention to the definition of the data structures.. then the methods that work on them come out very naturally. For me data = objects, and code = actions to perform on objects. I like OOP very much, but with no silly overhead of those languages that gave a (very unjust and unfair) bad name to the OOP methodology.. which has nothing to do with overhead per se (bad implementations have, but that's completely another story).
Posted on 2002-12-14 15:36:07 by Maverick
Learn as you go...

This is a topic that has been discussed many times over... and each time i try to walk away with some good ideas and implement them. And i usually do. However, as a programmer its not ez to 'reprogram' how you operate and stay consistant (well at least for me ;) )

This is why i say its a "learn as you go" experience. There is obvious wrong approaches, but my conclusion is that there is no 'templatable' right solution for any one person.

For this reason, each new project i start, i try to think of one thing that would make it smoother, and focus on it. That way if its a good idea, its a safe bet it will be inherent in the way i work by the time i finish up the project.

Some the project bettering topics that come to mind are:

Learning Macros (This was a slow learning curve, but a 500% return. Its probably the single-best thing I've embarked upon, and use it in practically in every project).
Message loops (some loops get pretty hairy to deal with, desinging a way to keep just enough of it in your attention has been some what of a focus (big if/elseif cases are annoying to look thru))
Document / No document (Tough topic! Too much documentation in your source makes the source very long and you loose track fast, not enough and you'll get a migrain trying get back up to speed after 3 days off). Im still trying new ways in this area.
Excell sheets (For tracking and taking note of each modules progression and headaches (so you can come back to a project l8r on). I prefer this over notepad from experience)

There are others...
Anyways, this is just how im dealin with such things. It works for me, but may not be your "template" ;) But perhaps it will give you some ideas...

Best of luck!
Posted on 2002-12-14 22:48:26 by NaN
Well the way i do it is. the


are all in diff files. normaly i move it over to the files after i have finished the proc or process.

Then I make sure to split my work up into Procs. That way i dont have one strait code segment that is hard to trace through.

its also good to split like the processes that are pritty much a diff program all together into another file and just include it the code sections like include .\decryptproc.asm that way you have another file that is like its own program but is used by the other one and you normaly leave its .data code in its file.

it helps alot with sorting things out. i have over a 5000 line code program and i can trace down almost eveything.


include .\datanormal.dat

include .\dworddata.dat

include .\decryptproc.asm

end start.

by doing this it cuts down on the main file you work with to organize the code and direct it.
Posted on 2002-12-15 02:35:21 by devilsclaw

I just dump all my codes into one file. haha... that's why I tend to hard to read c or c++ codes that spread into many files and stuffs like that. :grin:


That is exactly, what I am always struggling with. I just don't find my way through all those small source files :)

However, in school we get used to the modules approach, to split it up in small module packages, so that you can get an overview easily and to be able to exchange one module very fast and uncomplicated.

Regards, YaWNS
Posted on 2002-12-17 14:29:42 by YaWNS