How do you code?

[Thalius]

How i do it..

1. Get the Idea.
2. Plan some basic structures i will need ( Afterall it all starts how you organize your data ) - for this i often use notes ( paper, notepad whatever ).
3. i start writing pseudo code like:

Code: Select all

; Functions
; -> InitMyApp() - Initializes blahfoo
; -> MyApp_LoadThisAndthat() - Load Attributes from Prefs File...
; -> MyApp_ProcessThisandDoThat()
; -> MyAppCheckThis()

; -> Mainloop()
;    -> MyAppCheckThis()
; etc...

Together with the structures then you got an idea how the code will work ( build it in your mind then start coding ). If i am not sure if or how some stuff works i usually make some dirty, heavly debugged example Codes.

Well, that show i do it.. Sure, takes some time into planning but afterall you basically can code away without big try and error and think-over-recode-and-shit-where-did-i-use-what-variable-again...

As last: use Structures to keep stuff organized, pass pointers and use variables liek a, b, c ,i , x .. for loops and such. Plus writing some meaningful Varnames that you can sort out where you used them helps alot to keep the code clean and avoid odd bugs.

Cheers, Thalius

[Dare]

How do you code ...?

I code badly.

However I do a fair bit of prework before I write the crappy code.

1: Prelim
Define the objective.
Analyse the data (everything is data, understand the data and you get the solution).
Work out the quickest (least effort) way to achieve the objective.

2: Design
Mock up user interfaces
Scribble out flow diagram if needed to clarify idea.
Write code, testing often.
Reduce everything possible to procedures (and now macros as well)

3: Testing
As I go
After I think it is completed, I try to fool/crash it, and get others to do the same.

4: Document
Documentation is important. Later I might forget what I had done. Main documentation is in another (text) file, not the code.
In code comments are limited to right-hand-side shorts, and never of the

Code: Select all

n + 1                  ; Add 1 to n

variety. These sometimes refer to a note in the documentation. There are lots of these shorts, especially for variables and structures/fields in structures.



Note:
With the stuff reduced to procedures/macros, turn these into little black boxes in an include file. I reuse a lot of code.

Once a black box procedure/macro has been used in a released app, never change it unless prepared to recompile and retest every app that uses it - otherwise a mod or upgrade to a working app may turn around and bite you. Bad news when a "quick change" becomes a slog because something once safe changed.


The process "know the objective, understand the data, keep it as simple as possible and document the end result" works for me. Now if only I could code well ..

PS: I don't get hung up about producing anorexic (smallest possible) or clever/cool code and when possible avoid writing anything that is hard to follow or understand. After all, a dipstick (me) is going to have to maintain this stuff - a year from now I need to quickly know what is what.

[zapman*]

[quote="Trond"]Here's the number one tip: Keep DRY.
DRY = Don't Repeat Yourself.
[quote]

I totally agree.

Split you code into procedures and reuse them as often as possible in all your applications. Then, you code:
- faster and faster
- clever and clever (because you improve your procedures at each time)
- more and more secure. Each time you find a bug, you improve all the application using the faulty procedure.

Making libraries for each type of need is the secret. Publish all what you can. Sharing code allows you to get free testers and - sometimes - some improvment coming from outside. Your value is in your head, not in your codes. Don't be afraid to share.

I allways try to program "layer by layer".
-The first layer is a set of libraries doing the "bad" (technical) jobs (Internet communication, gadgets management, data management, etc.). It's the more hard and long to do, but when it's done, you have eat what you had to and you can put your energy on the dessert. I allways begin by this one to be sure that I'm able to do the project. If the technical layer is OK, I know that I can finish the job. If it is not, my time has no been lost because I've learn some more technical tips, even if i did'nt go to the end of the problem(s).
- The second layer is the user interface. How will you organize the data presentation? How will the user enter its data and settings? A very important layer.
- The third one is the functionality layer (data computing), the more interresting one (for me, at least)

[remi_meier]

http://en.wikipedia.org/wiki/Divide_and ... _algorithm
for the whole project on a paper. Then some flowcharts for some complex
functions.
Also: no procedure should be larger than the screen height.
I give every procedure a prefix which identifies to which 'class' it belongs
(gev = GUI events, scr = scanner, par = parser, etc.).
And yes, comment the more complicate parts of the program.

[srod]

Also: no procedure should be larger than the screen height.

Some of mine run into hundred of lines!!!

I give every procedure a prefix which identifies to which 'class' it belongs
(gev = GUI events, scr = scanner, par = parser, etc.).

Good idea that.

I'm pausing the app I'm writing now to break it down a little more. Self contained procedures (requiring no access to main program variables or constants etc.) will now go into their own include files etc.
Think I'll do this before it gets too out of hand!

[Trond]

Also: no procedure should be larger than the screen height.

I follow that rule as well. And with my large font I can only fit 30 lines on the screen at once.

[Kale]

From the 'Good Programming Style' chapter in my book:

Golden Rules For Writing Easily Readable Code
Here is a list of golden rules I follow while writing a program. I stick to these rules even when writing very small programs. If you follow this list you too will write good, clean, understandable code. Using a standard way of working gives your code clear and concise structure to anyone reading it and will make your code look and feel more professional.

1). Give all variables, procedures, arrays, etc. clear, accurate, pronounceable, descriptive names.
2). Group logically connected variables or data into arrays or structures.
3). Procedures should perform one function and perform it well.
4). Use indentation to show code structure.
5). Use parentheses (brackets) in expressions to avoid any evaluation confusion.
6). Use blank lines to separate different procedures and other blocks of code.
7). Try not to use the ‘Goto’ or ‘Gosub’ keyword.
8 ). Use comments to help people (or you) understand your code more clearly.
9). Try not to document bad code with comments, re-write the code properly.
10). When working in a team, agree a formatting style before starting, then stick to it.

I'm sure there are more.

EDIT:

Regarding GUIs: I usually draw the GUI on paper to get a feel for how it should look. Then use the standard Visual Designer to create the GUI. Then i use the exported code as a foundation, after that, recode it by hand according to my personal code formating rules and using the values from the VD code.

[remi_meier]

Also: no procedure should be larger than the screen height.

Some of mine run into hundred of lines!!!

Well, the reason is simple: With procedures, you can give names to
some blocks of code and split up complex things to more readable and
easier to manage blocks of code.

Like:

Code: Select all

Repeat
  ClearScreen(70, 70, 200)  ;{ ScreenThings
  ExamineKeyboard()
  ExamineMouse()
  If Pause = #False
    MoveSBubble()
    MoveThings()
    If CheckCollisions() = #True
      ReleaseMouse(#True)
      MessageRequester("Ende", "Anzahl Punkte: " + Str(SBubble\Punkte))
      ReleaseMouse(#False)
      InitSBubble()
      InitBubbles()
      InitStones()
    EndIf
  EndIf
    
  If KeyboardReleased(#PB_Key_Escape)
    Quit = #True
  ElseIf KeyboardReleased(#PB_Key_P)
    If Pause = #True
      Pause = #False
      ReleaseMouse(#False)
    Else
      Pause = #True
      ReleaseMouse(#True)
    EndIf
  ElseIf KeyboardPushed(#PB_Key_LeftAlt) And KeyboardPushed(#PB_Key_F4)
    Quit = 1
  EndIf
  
  DrawAll()
  If Pause
    StartDrawing(ScreenOutput()) ;>
      DrawingMode(1)
      FrontColor(255, 0, 0)
      Locate(20, 20)
      DrawText("PAUSE!")
    StopDrawing() ;<
  EndIf
  FlipBuffers()  ;} EndScreenThings
  
  Event = WindowEvent()
  If Event = #PB_Event_CloseWindow
    Quit = #True
  EndIf
  Delay(1)
Until Quit

is just not easy to read (even if it fits one screen height here (it should be
the maximum)). It's much easier like that:

Code: Select all

Repeat
  ClearScreen(70, 70, 200)  ;{ ScreenThings
  ExamineKeyboard()
  ExamineMouse()

  If Pause = #False
    UpdateGame()
  EndIf
  
  ProcessKeyboardEvents(@Quit, @Pause)
  
  DrawGame()

  FlipBuffers()  ;} EndScreenThings
  
  Quit = ProcessWindowEvents()
Until Quit

(You could even more simplify it )
It's perfectly compatible with the "Divide and Conquer" approach, when
you divide a problem that much that you can just write its procedures
at once. Those are mostly very small if you did it right

[MadMax]

First of all, I usualy just code for fun, my main source of income is other than computers.

Second, I'm the only coder of my projects. Used to code with a friend and there we had to come to some sort of agreement, but he married and he no longer codes, although he now makes some nifty airplanes for Flight Simulator.

So how do I code? Well usually I say "How could I do this?" or someone comes to me and says "I'll pay you $$$$$ if you can write some code that will do this?"

In the first case I decide which lang(compiler/interpreter) I'd like to use, in the second case this is usualy imposed.

A) In the first case there is no problem, I know what the program is meant to do. In the 2nd case I spend quite a lot of time discussing about the program and making sure I understand what the program is expected to do( not that straight forward, as not always the person you have to deal with is that sure). Meanwhile if the lang I'm meant to use is not very familiar I go trying out simple routiunes I think might come in handy.

B) Once I know what the program should do, well depending on cases there I am speaking to a "system manager" seeing what he will let me do or not, using a lot of pencil and paper, coding routines to see how they work etc etc.

C)Now basically, the difficult bit is over, now it's just down to coding and hope all works as expected, of course it rarely does, so test, test, test, test again... Recode, patch, fix that bug, fix this other one. Sometimes you are unlike and your main code design will need so many fixes that unless you are working for.... (OOOPS! silly joke!). In this case you have to sit down and maybe try a new strategy.

D) A few changes here a few there, and voila it's done, and hopefully they shouldn't bother you again, and they usually don't, we'll not with the same program

[Derek]

I just jump in and start coding!

I try and get a main loop going and then just add procedures at the end and any arrays etc at the start.

I tend to just shove datasections in here and there and then when I go back to the code a few months later I can't see how any of it works

Never mind, I only code for fun and the odd program that I use at work.

[Character]

I think Derek is right.
It depends on how much you code also.
I can imagine when you are a professional or just an intensive coder things need to be as efficient as possible.
Me myself and I, just code once in while for fun.

But I promise, like posted before, that I will do my best to avoid bad habbits.

[spongehammer]

Here are some more suggestions



http://www.purebasic.fr/english/viewtop ... highlight=

[netmaestro]

Visualize.
Type.
Curse.
Type.
Curse.
Type.
Pull hair.
Type.
Post forum question.
Cut-and-paste answer.
Sign my name on finished program.

-Redo from start

[White Eagle]

How do you code?

Naked

[Character]

Naked