Coding style and getting things done

I know that this has been asked many times before but I always find it useful to hear how other people do things and I also think it is a great read for anyone new to the site since it was last discussed so...

What is your coding style?

Do you comment your code or do you feel that code should be easily readable if you have done things properly in the first place?

Do you use include files or do you have everything in one source file?

Do you plan thoroughly before even typing a line of code or do you play it by ear?

Finally, do you use a todo list?

Please feel free to add anything else that you may think is relavent.

Jason.

Mine, I guess. I'm not sure how to answer this. I'll tell you what, my coding style isn't complicated or "clever", I make it simple so that I can understand it a month later if need be.

Yeah all the time. I think the "easily readable" argument doesn't hold much water if someone who doesn't know the language has to overview your code, and also a single comment before a largish chunk of easily readable code means that you don't have to figure out what the chunk does when browsing, you can just look at the comment.

Yeah a couple but it turns out that my projects don't have as many sub files as some other people use round here.

Most things I plan in overview and then I just get on with it. Some more complex things I plan in more details, either on paper, on a spreadsheet or in my head. Sometimes the "get on with it" approach fails and requires a rewrite due to something you didn't account for.

You bet! I actually have an overview to do list so that I can see major progress and then my main to do list is broken down into all sorts of sections and each item has a Prioritisation column next to it which includes High, Med, Low and I change it to DONE or NO (if I don't do it). I put all the "cool things" I think of in a polish list instead of coding them straight away. Also I have a "Cosmetics" section in which I log things that aren't perfect but are good enough for now. I could go on about to do lists for a while because I've been developing them over 10 years and I think I have a pretty good system now.

Maybe I'll add something about motivation. Sometimes I don't want to code something for whatever reason like I think it may be complicated or boring or I'm just in a procrastinating mood. Anyway I find the best cure is simply to start work on it (and put on some uplifting trance music (or whatever works for you)), and after say 10 minutes I find that I'm well into it and enjoying myself.

Thanks for starting things off Grey. Some very useful points there.

I do find the motivational thing the main killer I must admit. As an artist I`m fine, I just get on with it but as I am not a natural programmer I find it really hard to get going with coding. I also find that I will code for a few hours and then scrap the whole lot because I think that I could have gone about it another way. Because of this nothing (coding wise) is getting finished. I also find that I try to make things as flexible as possible and this also causes me lots of headaches that I could probably have avoided.

Like I said this isn`t a problem with the art side of things. I`m guessing though that this probably is the opposite of people who are good at coding but not drawing, I hope so anyway :)

Another thing that puzzles me is that when I had an Amiga and Amos I used to be very productive but now that I have a PC and Blitz, despite having tons more power at my fingertips, I just cannot get going despite having lots of great ideas. It`s like a mental block.

I work really well when I`m on a schedule but without one I`m knackered and I don`t consider myself a lazy person either so I`m not sure what the problem is.

Maybe I`m just not a coder?

Jason.

Making things flexible is good practice, but it can be very time consuming and many people fall in the trap of making stuff flexible that they never use again. Sometimes, especially if you are less experienced at programming, it may just be best to get on and code something non-flexible and if you need to make it flexible later, then do it then.

Also don't scrap code if you realise you could have done it better, just get on and do the next thing so that you can actually get something finished. Next time you code a similar thing, you'll hopefully remember the better way and do it like that.

You've got to strike a balance bettwen "perfect" code that takes forever to plan and write, and actually getting something done!

Me I always programme Backwards

1.Concept
2.What It needs
3.Spyder out the Task
ie I need some code to manage 100 entitys so ill dream up something to handle 100000 entity rewrite tweak rewrite
once Ive got a good performance ill down scale and green light the code go on to next task

I heavily Group and Include Files so i can have something like 4 or 5 versions to swap them if needed to refine the overall programme

Then Ill Bring it all back together in a logical order
Ie Set a target knock something up and break it.
I suppose I try to debug the code at a stage before the problems arise.

I also like to store and reuse code that works well if it aint broke dont fixit.

As for commenting Ill only do this on early designs and remove later or make path notes for heavily linked functions to keep track of paths

I severely improved my code style during last 2 years, as it not only helps much to keep program structure and elements in mind, but also easies understanding of code for others (it's valuable for OpenSource programs support).


If I write progs for myself - almost never. If I currently working on this program, I remember everything without comments. Though, if I'll try to dive in my old progs, I'll probably got problems 'cause their structure is wiped from my memory. And if I write public programs (to my e-zine articles in particular) I prefer to comment anything that cannot be understanded after first look.


Prefer to separate only blocks of code which are hardly tested and do not require additions as I hate always switching to main module for execution when debugging. Also programs with additional modules are harder to post. Though when program becomes too big and code masses starting to hinder much - prefer to split prog too.


For almost every program it's easier to think about basic structure and algorhytms first than finally rewrite it from zero after. But some things will make clear after some coding and testing - new ideas about how to optimize or expand program born. And some algorhytms require pen and paper (or something like MathCad) to solve :). But what is already tested and developed doesn't require thinking, so I can write big amounts of code with familiar behavior without planning using just my intuition.


Not yet.

Also I can add things I also found useful in code formatting: whitespaces (tabs); writing understandable variables and functions names like "SetUpObjectLayers"; marking types with "T" ("TSprite"), constants with "_" or some other headers; dislike very much to write repetitions of code blocks (think about squeeze 'em in cycles, etc); type spaces after commas, after and before operators.

BTW, can anyone explain about real "SuperScript" benefits?

In general, I try to work as clear as possible. However, in practice, I don't allways do that. When a code became too messy, I clean it up later on, at a point where I don't know what to do next or when I want to start a new part of the program.

I believe there should be a balance between doing things properly and actually finishing stuff. But usually, if I write clean, commented, code, I am thankful I did that later on, because it makes it possible to change/replace stuff in a sensible manner.


Without comments I find my code unreadable. So I comment every block of code. I also work with clear labels for each part of the program.


I find including everything much handier, because later on, you can replace stuff if needed.


Before trying, I plan on paper what I want to do. I also make smaller examples to try out different concepts.
Usually, this example becomes a separate module that I can include later on.


I have made about 128 todo lists allready, and still using them. It is a good feeling to scrape things from it.


Before trying anything new, I make a backup of my old program/folder. I give them numbers. I usually end up having about 40 copies of the same program. It is nice to see how it evolved later on.

In BB, this is my ideal coding style:

;-------------------------------------------------------------------------------------------------------
;													Globals
;-------------------------------------------------------------------------------------------------------

	;if debug mode should be enabled
	Const 	debug = True
	
	;type that contains enemy data
	Type Enemy
		Field x, y
	End Type
	
	;score
	Global	score
	;time
	Global	time
	;arial font
	Global	fontA
	
;-------------------------------------------------------------------------------------------------------
;												      Init
;-------------------------------------------------------------------------------------------------------

	;setup graphics mode	
	Graphics 	800, 600, 0, 2
	SetBuffer 	BackBuffer()
	
	;load all graphics
	InitGraphics()
	
	;set time to 100 sec
	time = 100	
	
;-------------------------------------------------------------------------------------------------------
;													Main Loop
;-------------------------------------------------------------------------------------------------------

	;main loop
	Repeat

		;decrease time
		time = time - 1
		If time < 0 Then Exit
			
		Cls
		
		;draw rectangle onto screen
		Rect  0, 0, 64, 64, 0
		Text  32, 32, time, 1, 1
				
		Flip
		
	;esc=exit
	Until KeyHit(1)
	
	End
	
;-------------------------------------------------------------------------------------------------------
;												InitGraphics()
;-------------------------------------------------------------------------------------------------------
;initialises graphics
Function InitGraphics()

	;load arial font
	fontA 	= LoadFont("Arial", 60)
	SetFont fontA
	
End Function

I have improved it over time, and for me this works: even after a long time, I am able to read and understand it, and that is what I find the most important about my coding style.

yeah I make backups of my code and increment the version number after major work is done. I also store the exe and data too so I can run the old versions if need be. I also keep a library of screenshots. It's quite funny looking back at early versions of a game to see how it evolved.

I don't get this 'my code is easily readable, so I don't need comments' argument that some people use. No matter how easy the code is to read, you still have too look at it and interpret it to see what it does. It's much easier to just read a comment that says simply and clearly what the code does. That's an important point - comments need to be clear and succinct. I often spend more time thinking how best to comment something, than I do writing the actual code!

Good code commenting is a bit of an artform, really. You dont want to overdo things so that the code gets burried under a mass of comments. You also dont want to be too brief so that any commenting is next to useless. It's a fine line. I also find it's easy to write a comment that seems to make perfect sense as to what's going on at the time - because you have all the info in your head - but when you come back and read it later, it's far from clear, or is ambiguous.

I'll use include files for bigger projects but I generally try and keep them to a minimum, these days. It can be tempting to bung every single related bit of code into a separate include file but I find this can lead to keeping track of things much harder.

I find it's more important to name things logically and consistently. For example, name all functions that update something, update_this(), update_that(), update_other() - functions that create something create_this(), create_that(), create_other(), etc. This way, you should find it easier to locate the peice of code you want to look at.

I plan and workout stuff on paper before coding something moderately complex. If you just dive straight in, you'll almost certainly come a cropper. In the past, I've also found flow charting systems/algos very useful. It helps you see the whole picture by laying everything out in front of you, in easy, logical steps.

If I need to add something quite complex to a project, I code it in a separate prog, get it all working the way I want, test it thoroughly, and then add it into the main project source. This helps me concentrate on writing the code to do the specific task, without the distraction and clutter of the other project code. Of course, when coding separately like this, you need to keep in mind that it has to be module enough to plug straight into the main project code.

Of course, with easier stuff, or stuff you've done before, you can just dive straight in. :)

I do, but nothing like as organized as Grey. I just jot down anything that springs to mind as I go along, really - mainly bugs that need fixing. :P

I suppose my coding style is methodical or modular. I generally like to get all code related to one thing done before moving on. This means I can focus on the next thing more easily and also break it down into more managable chunks.

Yes, even if I'm the only one who is ever going to read them I like to comment them as then I can come back to them and understand the code quicker if it needs to be changed.

A little, I like to have as few as possible as I can keep track of them better then. I like to group code that does a similar task like all code to load things in one file.

It depends, the more complex the code the more planning I do but usually I plan on paper before coding anything, often I end up replanning the plan.

Yes, todo lists help a lot to keep track of what's done and what needs done. If you're writting something big like a game I think todo lists are essential. I like to write a todo list on paper and it will last a week or two before I'm finished and I can start a new todo list. It really helps me keep my motivation/focus.

Pretty 'standard' I'd imagine, hard to describe really except that I try to make all my functions seem obvious in what they do... *see below*


Sort of. I use BLide as my editor and it has the nice option of 'code folding' which I use extensively and as an alternative to a lot of commenting. It also makes the code look neat and tidy. ;)

When I start writing a program I have everything in one file, then when I feel it's going somewhere I'll turn it into a project (BLide again) and spread things out a bit with includes.

A little from column A, a little from column B. I have several little notepads with random ideas for themes to code snippets I want to try. I don't plan things out to the letter as more than likely I'll need to change something. I usually just have a general idea for a game, get some basic functions running, review them with my little notepad and rewrite it with necessary changes, then repeat, repeat.


Only if I'm doing something rather complex. Most of the time I know what I need to do, when.

I break my project up into modules and heavily comment them. You'd be surprised what taking a month-long break will do to your being able to read your own code if you don't.

A ToDo list is an absolute necessity. Also set hours for yourself and don't work into the night until 4am. Makes for huge bags under your eyes and you'll look like crap. I probably code no more than 3-4 hours a day. After awhile you lose your edge and start getting sloppy and rushing.

I skipped ahead so I could post before bedtime


This is pretty much a loaded question, if you ask me. But I am one that tries to develop very flexible code. Things I can use for multiple applications, or can reuse should my current plans change. I end up writing modules and using them in whatever application that can take advantage of it.


I comment my code extremely heavily. My sourcecode has practically the complete project documents in with it. My source is probably only 50% actual code, and the rest is comments. Maybe I just like to keep all the info showing in one program verses having several instances of Notepad running. All my functions include a header which details what the function is used for, and what all the parameters do. For modules that I write, this usually serves as the usage docs.

I generally try to put comments in for large sections of code. If you don't look at the code for too long, you can take guesses at what a certain block of code does, but you can't be certain. I find that sourcecode doesn't provide enough information about what processes are actually taking place. It tells you each step of what it does, but not what its ultimate goal is.


I use a great deal of my modules, so I have all kinds of source files. I tend to not like to search through my code so after about 500-800 lines of code I'll start dividing a file into includes, while organizing the functions into each file as best I can. I'll even do this to modules of mine, and keep them all in a unique folder for each module.


I used to start 'head-first' into a project and try to code something, anything up. But I find that more and more difficult to do. Usually you spend most of your time trying to figure out what it is that you want, instead of coding. Plus I carry a pen & pad of paper with me everywhere these days, so I jot down ideas in that. I seem to end up with quite a few 5-minute spans to stop and plan things out. Trouble is, I end up having very little time to put anything together at the PC, so I end up having lots more ideas and tasks than actual completed work. It sucks.


I find having a todo list helps you jump back into developing a project quickly. Rather than sifting through your existing code, running to see how things are going, you have your next objective there to start from, and you get started right away. I've never found a need for prioritizing tasks. If I choose to do them later I copy-paste them somewhere further down the list.

I keep a task list for each project I have, and then one for everyday things. That list never gets smaller, it seems. Maybe I spend too much time playing games.

As far as my style goes, it's nothing special. I use comments and have plenty of space. I hate chunks of code together with no line-spacing, as it makes it harder to read, imo.
And I try to make the code easy for others to read too, since the majority of stuff I'm doing of late is for public consumption.

Commenting is important. People who say the code comments itself is talking out their arse ;-)
I don't believe that having to spend time reading someone elses code just to understand what's going on is very productive. Even your own code, if it's something you did a while ago and need to revisit.
It's not like commenting takes very long to do.

I try to break my code up into reusable parts. Plenty of imports. I guess I'm too used to Java in that respect. I also tend to refactor quite a bit as a project develops, and having things in separate files already helps that.

I'm not very good at planning things.
Generally, I know what I need have at the end of the day, and work towards it.
For example, in my latest project to handle EXR files, my first aim was to get a single image to open in BlitzMax. This is done reading specs, looking at examples, googling, and lots of trial and error. Once I have the framework, I can sit down, re-factor the mess, and create something more useful.

I probably should use TODO lists more often. I've found with big projects, such as the Qt GUI module, I've needed one, if only so I don't have to remember what bits still need fixing.
I tend to have TODO bits in the code itself, like for a function that I haven't written yet, but I know what it needs to do.
This all kind of goes back to the refactoring thing... write stuff - get it working - refactor to make it more useable.

Perhaps I just like making work for myself ;-)

@Grey

Do you use any software for your todo lists as they seem as though they are quite complex or do you just write it down on a notepad?

I tend to give up on projects easily as my coding skills are not really that good and when I come accross something I don't know who to do I just put it to one side and in most cases, don't go back to it.

Perhaps as in big10p's case I should plan something on paper first bofore I tackle the coding side of things.

Modular and reusable as much as possible.

I frequenty write code in pseudo code comments then convert it to real code leaving the pseudo code in.

Yes, many many includes, as I said, modular and reusable as much as possible.

Not at all, I should do though. As I said I create a blank file and pretty much write in English what I want it to do... then turn each sentence into a block of code.

I usually come up with a todo list when I can see the light at the end of the tunnel so to speak. Then there's just a handful of items that need to get ticked off and you're just polishing after that.

Short, to the point, and straight-forward. To me. I tend to lean more towards procedural coding and other C-programming habits.

Both.

I separate code based on categories, its intended task, etc. Depending on the project, it may be a single source file, or thirty.

Planning takes too long and things change too frequently to justify any extensive planning. I tend to have an idea written down, but beyond that I will not do any thorough planning.

My opinion is that todo lists are for people who have something to do, but would rather know they have to do it than actually accomplishing that goal. If you have something you need to do ahead of what you're doing, write it down and get back to work.

I don't go "hm, which item on this list do I want to do first." If I'm doing something and I notice something else needs to be done, I make note of it, but I just go back to work.

Edit: Random source code to more or less illustrate how I work.

SuperStrict

Import "head.bmx"
Import "resource.bmx"
Import "lua.bmx"

Private

'
Type scriptfunc
    Field cb:Int( s@ Ptr )  ' Callback
    Field name$             ' Function name
End Type ' scriptfunc

' List of scriptfuncs, used to store the engine's glue functions
Global _scriptfunclist:IList = New IList

Public

Function ScriptFunction( cb:Int( s@ Ptr ), name$ )
    Local sf:scriptfunc = New scriptfunc

    sf.cb = cb
    sf.name = name
    _scriptfunclist.AddLast( sf )

    If IScript Then
        IScript.RegisterFunction( name, cb )
    EndIf ' If
End Function ' ScriptFunction

' Hook.  Used for initializing global variables and such.
' Glue functions are stored in the function list, and added
' every time the script engine is initialized.  No need to
' add them on initialization with the hook.
Global ScriptInitHook% = AllocHookID( )
' Global script state
Global IScript:Lua = Null

Function InitScriptEngine( )
    If IScript Then
        Return
    EndIf ' If

    IScript = New Lua
    IScript.Reset( luaL_newstate( ), True )
    IScript.LoadLibraries( )

    ' Load the glue functions
    For Local i:scriptfunc = EachIn _scriptfunclist
        IScript.RegisterFunction( i.name, i.cb )
    Next ' For

    RunHooks( ScriptInitHook, IScript )
End Function ' InitScriptEngine

Function LoadScript( name$ )
    If Not IScript Then
        InitScriptEngine( )
    EndIf ' If
    Local r:TStream = GetResource( name )
    Assert r,"Script ~q"+name+"~q does not exist."
    IScript.Do( r, r.Size( ), "game_main" )
End Function ' LoadScript

Function KillScriptEngine( )
    If Not IScript Then
        Return
    EndIf ' If

    IScript.Dispose( )
    IScript = Null
End Function ' KillScriptEngine

' Dump the Lua stack into the debuglog
Function DumpStack( )
    If Not IScript Then
        DebugLog "Script engine not initialized"
        Return
    EndIf ' If
    DebugLog "<<< BEGIN STACK DUMP >>>"
    For Local idx:Int = 1 To IScript.Size( )
        Select IScript.GetType( idx )
            Case LUA_TUSERDATA
                DebugLog "Data at "+idx+" is a pointer: 0x"+Hex(Int(IScript.GetPtr(idx)))+"  "+Int(IScript.GetPtr(idx))
            Case LUA_TBOOLEAN
                DebugLog "Data at "+idx+" is a boolean: "+IScript.GetBool(idx)
            Case LUA_TNUMBER
                DebugLog "Data at "+idx+" is a number: "+IScript.GetNumber(idx)
            Case LUA_TNIL
                DebugLog "Data at "+idx+" is nil"
            Case LUA_TSTRING
                DebugLog "Data at "+idx+" is a string: <<<"+IScript.GetString(idx)+">>>"
            Case LUA_TTABLE
                DebugLog "Data at "+idx+" is a table"
            Case LUA_TNONE
                DebugLog "Data at "+idx+" is value None"
            Default
                DebugLog "Unknown data at "+idx
        End Select ' Select
    Next ' For
    DebugLog "<<<  END STACK DUMP  >>>"
End Function ' DumpStack

' Convenience function that calls Lua.FromState
' (because I'm lazy and don't like writing Lua.FromState over and over)
Function FScript:Lua( st@ Ptr )
    Return Lua.FromState( st )
End Function ' FScript

Messy, disorganised, lots of code re-used, copied and pasted all over the place. Loads of global variables. Loads of functions. I do use tab religiously though, visual structure is important to me.


I don't comment anything. Instead I use really long function and variable names, like:

CheckIfEnemyBulletCollidesWithPlayer()


Generally I'll put everything in one source code file, unless I'm using someone else's include file.


Neither works for me.


No. They depress me.

Keep it simple, keep it documented and make it robust. There's no need to re-invent the wheen for every new project when you can make all of your code robust so that it can be re-used for multiple projects.

It may take longer to write robust code (maybe 3 times longer than just slapping together code that works for the one job), but that time is saved when the code is re-used (if you use it for 10 projects or functionalities within a project, you've more than reduced the work by 3 times).

In addition, when you program software for other people, you learn very quickly that the client will often add new requirements into the project. This is all fine when you've only wrote a few lines of code, but more often than not, the client will ask for new things when there are thousands of lines already developed; the more you write, the more difficult it becomes to add unexpected features and the more chances there are of new bugs being introduced. By making code as modular and robust as possible, it becomes easier to add new features.



This is a must. It only helps you to be able to re-use your code at a later date, plus helps if you need to bring in other programmers to the project. Having re-usable code will help you to be more productive and save you money (in terms of time and if you have to hire other programmers).



I put everything in separate files. For commercial work, I have developed my own engine in PHP which has specific classes (each in their own file) that are responsible for specific functionalities. These include:

* database operations

* gui drawing - I have defined gui elements such as combo boxes from CSS, plus have various functions for drawing file requesters; all I have to do is call a function and it will create the HTML that is needed

* Graph drawing

* File management - uploading, directory reading, etc

* XML creation

* etc.




Yup. When you program applications for other people, you need to get a specification down in writing, or there will be a fair chance you'll get shafted by the client and end up delivering more than what you agreed to for the price.

This would probably be good advice if you are ever approached by a games publisher to develop a game; always get the specification in writing so that all is clear. The problems that occur is often due to non-programmers thinking that a feature is easy to develop because it sounds easy.


First I split a project into milestones, then I create a to do list from each milestone that I work on. After this, the process goes back the drawing board for maintenance and design due to changes in demands from clients. Check the waterfall model http://en.wikipedia.org/wiki/Waterfall_model



I have developed a variable an class naming convention to help keep everything understandable and consistent. Example:

exVar - is a variable
exVar_exGrp - is a variable within the group of variables starting with exVar
exVar_newGrp - is another variable within the group of variables starting with exVar

This style helps when searching for related variables. Same can be used for classes and functions.

What is you coding style?

applications, no games
OO without inheritance, lots of event(hook)-communication between objects, everything local, no globals, somewhat unconventional application-operation. I'm not much following those standard UI guidelines, instead I consider an app like a musical instrument: first learn to use it and then enjoy the speed-comfort.

Do you comment your code or do you feel that code should be easily readable if you have done things properly in the first place?

Rarely, only at the start of a group of instructions that -combined- do one thing. And only if there are more of such groups within one scope (like a Method, Function, Case or If). My code is self-explanatory. I avoid super-long function/method-names or variables. I indent and whiteline a lot.

Do you use include files or do you have everything in one source file.

Usually I create a new type in one file, including related things. When it's done and tested I'll dump it into an import file.

Do you plan thoroughly before even typing a line of code or do you play it by ear?

Depends, when I estimate that a small application has only one function then I don't bother about being tidy. When an application is to become big (4000+ lines), then I usually think a bit ahead, mainly in terms of readability and splitting-up functionality into standalone code.
Additionally, I prefer not to bugfix a lot, I rather toy around with something during code for a while. I want something bugfree and clean before I continue enhancing it.

Finally, do you use a todo list?

No, other than the one in my head. If code is good and sustainable then a todo doesn't really matter, you can just add something when you think of it. The important bit is then to have a code-core which you can easily expand with functionality without messing-up something. Note that I mainly make creative applications, and by using such an application I come up with new functionality and controls every now and then.

Enigma: I know there's tons of good software out there, but I just use excel. Then I can attach time estimates to tasks and have it add up the total. Also you can use the sort function to reorder your to do list. Excel is pretty flexible. I also use it top log my time spent on the project, broken down into categories, so I know how much time I spent emailing the producer, and programming, and plugging in graphics etc.

Aha, I see that Noel has returned. Hello.

This wouldn't work for me. For example, whilst working on one thing I may notice a bug or think of something else to add, so I put it on the to do list, finish the current task, and then go back to the other stuff - if at all, because if it's a polish item I may want to leave it until right to the end of the project. Also when working as part of a team you can quickly tell them what you are planning to do next, or what the overview is etc.

Lean and flexible.

Neither. I feel that code should be self-documenting. I start out with the simplest solution that could possibly work, and refactor until it's readable.

Imports. Lots of them. I start out with one gargantuan source file, and then break off each object as it passes the unit tests.

Neither. I tend to walk the middle line as it were. Quick prototyping in code - proper design on paper - proper implementation in code.

Sort of - although it's more of a sprintlog / backlog / releaselog thing, rather than a todo list.

Alternatively you can just give your methods sensible names. From personal experience I find you're going to have to read the program anyway, because the comments are hopelessly out of date - and even if they aren't, you won't know until you've read the code. Even in a best case scenario there's always the chance that the code doesn't actually do, what the person writing the comments thinks it does.

One thing I like to add, is printing out the code. I like to do that sometimes. It gives a refreshing new view of the program, and, if all the backups suddenly crash, you can retype it :D

b32: I prefer punch cards. Did I mention I routinely use binary Turing machines?

No, actually I can't remember you did. And, as a dedicated Turing machine user myself, I would have definitely remembered. Hey, if you wanna exchange pictures, please let me know ! Atm I'm working on a project that converts my code into ancient sanskrite, and then reads it out loud using the MS Speech API.

When making a project I usually will write and draw a lot of stuff on paper first to get a sense of what I want to do and how it might look or be achieved. I draw lots of little diagrams and write down my thoughts about it however it comes to me. I will go to the computer to write code usually only if I need to know how something might work, if there is research to do or it's time to implement something. I do quite a lot of work inbetween writing code becauase I want to have a good grasp of the overall situation I'm working on in order to step back and create a nice integrated solution.

I tend to write code with comments on most lines except where obvious because no matter how familiar I am with something, and especially if it is a bigger project, when I come back later I don't want to be spending time figuring out what something does or why I did it. I usually comment each function at the top of it as well. I like to make the code easy on the eye so I use uppercase first letters, I don't put in lots of unneeded spaces, and I try to align my comments in groups.

For a larger project I will try to draw out a chart representing the various parts and what I think will be their interrelations. That gives me an idea of what possibilities are implied and where the limitations are. I will then try to transfer that to a number of source files which I typically will Include from a main source. I have not used import very much but I'm starting to try to think in terms of making as much as possible into a module, including basic documentation, so that things will be tokenized and I can hit F1 to remind myself of parameters and other stuff. I usually try to keep one main custom type per source file, with all its accompanying methods/functions etc.

Over time I go back and rethink some things. A lot. :-)