flat assembler
Message board for the users of flat assembler.

Index > Heap > Describe how you develop your programs

Author
Thread Post new topic Reply to topic
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
Hey!
I think it will be fun to know.
Just describe what's your way of developing applications.
What you do first, then next, etc.
Let's share experiences! Wink
Post 24 Oct 2006, 21:25
View user's profile Send private message Reply with quote
coconut



Joined: 02 Apr 2004
Posts: 326
Location: usa
coconut
i have bad habit of going straight into writing pieces of code - no planning at all. which explains why my apps crash so much
Post 24 Oct 2006, 21:41
View user's profile Send private message Reply with quote
sylwek32



Joined: 27 Apr 2006
Posts: 339
sylwek32
1. I make a "blueprint" on paper of the programs skeleton
2. I create a programs skeleton
3. I am adding some "functions"
4. I am thinking what "backdoors" these functions have
5. I am removing functions which could crash the programm
and which could be security vulnerabilities
6. Editing the code..
7. I am cleaning up the code
8. I am looking at the code and i am optimizing it in speed and size
9. If all=right then me=finished
Very Happy

But that only happends if i program some better things like a webserver with his own prepr.
Post 24 Oct 2006, 21:43
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
cocount: apps do not crash (usually) because of no design. 90% times it's because of bad code, not design.
Post 24 Oct 2006, 21:47
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
HyperVista



Joined: 18 Apr 2005
Posts: 691
Location: Virginia, USA
HyperVista
1) rough draft on paper ... diagrams, arrows, scratches and sketches
2) psuedo code
3) sometimes use case cards to flesh out which functions call each other and how
4) rough code development - stub out lots of functionality - lots of print messages where functions will eventually be working
5) fully develop functions
6) finish
Post 25 Oct 2006, 01:57
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I don't do much programming stuff but when I need to do something I usually tend to use a top-down design. Sometimes I also use class diagrams even if I write in a non OOP language, it helps me a lot to find apropiate code structure. Note that I use it just as a guide since if the language is non OOP I do not use object emulation tricks.
Post 25 Oct 2006, 02:24
View user's profile Send private message Reply with quote
coconut



Joined: 02 Apr 2004
Posts: 326
Location: usa
coconut
no design leads to bad code
Post 25 Oct 2006, 03:05
View user's profile Send private message Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
Random scribblings on paper (I find pencil's the best) to remember stuff in my tiny brain, a few beers and some food to last me until 3AM if I'm feeling really enthusiastic. Also a lot of reading if I've never done whatever it is I'm doing before so another machine or books as well.
Post 26 Oct 2006, 19:26
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
no design leads to bad code

surely. but not to crashing. good-written bad designed code doesn't crash (well... seldom).

i first thing some design roughly, start coding it, after little while i find out design was bad, recode it, and this repeats several times until design is best i can work out. i never mind to rewrite half of code to get better resulting app.

btw, best place to think about design is toliet Wink
Post 26 Oct 2006, 20:25
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
I just break evey big job, into lots of little job, like if i was writing a floppy driver, the first job would be to write a turn the motor on and off function and so on.
Post 26 Oct 2006, 21:46
View user's profile Send private message Reply with quote
asmfan



Joined: 11 Aug 2006
Posts: 392
Location: Russian
asmfan
programs are written with paper but coded with computer...
Post 26 Oct 2006, 22:11
View user's profile Send private message Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
I used to have such a way: when any idea popped in my head, I sit in front of computer and coded. Then came the bugs, quick-written unreadable code, algorithms which were totally stupid (like cmp eax, 1... cmp eax, 2... ... cmp eax, 256, instead of jump table Smile) and functions' name which were similar to nothing (eg. 'is_good', '_is_good', 'is_really_good' in one program Smile). Also one thing I consider bad from my past experiences is communicating between procs/functions via global data. I never used any arguments. I just set another global variable.

Now it's somewhat different: first I think generally how is my program supposed to look/work. I start with the general things and end in details (still just thinking). Then if needed, I check some maths on paper (eg. what should be the input number to prevent the output from overflow). I code the main function, then the most detailed ones and link everything. I always try to write as universal program as possible (of course reasonably). For example, even if I have one window, and there's a prcoedure that changes something in it, I have window's handle as argument. Even though there's always the same argument passed, as there's no more than one window, I just see the readability of my code increases. I see what's the input, and what's the output. I also have my own programming style/convention, but that's a matter of taste
Post 27 Oct 2006, 22:07
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Then if needed, I check some maths on paper (eg. what should be the input number to prevent the output from overflow)

hehe, we are not C coders to need to do it this way. we have overflow checking!
Post 27 Oct 2006, 22:40
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
Yes, but in the program I am writing now it must be done. I am creating a keygenme (program with some security to break). The algorithm I design must be fully reversible and overflows can make some kind of input impossible to regain.
Post 28 Oct 2006, 14:18
View user's profile Send private message Visit poster's website Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
I design some of the programs while I'm (re)writing them, or when I'm going to sleep early I got few hours of spare time while turning around from side to side on my bed, I got bad sleeping problems, but I usually forget the designs I think of when I wake up Razz
Post 28 Oct 2006, 15:06
View user's profile Send private message MSN Messenger Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u
If i have a peace of code that does not work and i can not understand why, if i go to sleep the answer is always in my head in the mornning Shocked
I go to the PC and think, i will just try that before i go to work and so far it always worked.
So i am a better code in my sleep Wink
Post 28 Oct 2006, 16:12
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8885
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
i sometime wonder why i preffer complex approach over simple approach.

when first doing a code, it is simple
after a review, modify something then look a bit complex
then rethink again, scrap and start new Wink
then review again, enchance it more, now is quite complex Smile
then review again, why not just use simple approach?

lol. no doubt, human heart is ever changing
Post 12 Nov 2006, 19:52
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
N.B. These are the ramblings of a wimpy DOS hobbyist, so don't expect too much! Razz


  1. think of something that'd be useful (within my limited skills)
  2. choose language and (freely downloadable/usable) assembler/compiler
  3. install assembler/compiler (if not already)
  4. read docs, help files, tutorials (for language and/or assembler/compiler)
  5. view/modify/write a few sample programs to get comfortable
  6. choose target cpu requirements for intended project
  7. hack up a quick working version (within a few days, usually 1 or 2)
  8. write sparse help notes: usage, todo, bugs, etc.
  9. if it works, save/ZIP/backup-to-floppy it as version 1.0 (or 0.1, if it's really wimpy)
  10. come back to it later and add a new feature or two and/or fix a few bugs
  11. improve notes, add reference docs, make more compatible w/ other compilers/assemblers/OSes (#ifdef or via sed scripts), add simple test suite, comment better, write auxiliary .BATs (e.g., make, test, etc.)
  12. save as version 1.1 (or 0.2, etc.) sometimes including certain previous versions' source or diff (for safety's sake)
  13. rewrite it (usually necessary)
  14. save it
  15. rewrite parts of it (usually necessary)
  16. save it
  17. work on something else
  18. collect/document misc. notes about other useful computer things
  19. save it
  20. read FASM's forum, OS News, FreeDOS's news, etc.
  21. surf the web and update lots of nifty tools (e.g., UPX, TDE, GRDB)
  22. compare features of similar utils to my own (finds bugs in mine and theirs, gives me ideas too)
  23. update it, save it, etc.
  24. procrastinate
  25. waste time
  26. work on program B when program A should be improved
  27. be lazy
  28. real life (yuk)


In other words, I suck at planning.
Post 12 Nov 2006, 21:35
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.