How do you code ??

  • Thread starter Thread starter dal
  • Start date Start date

dal

dal

dal

Associate
Joined
10 Sep 2005
Posts
905
Location
Lincolnshire
Hi all, I was just wondering when you guys have a project how do you go about coding. Do you put it all out on flow charts first then code from that or do you just basically start coding from scratch.
I've got a project of my own (coding a simple(ish) game) & I just started coding from scratch, which has been ok but now my project has got a bit more complex It's becoming quite time consuming putting things right when things don't work as intended.

I'm thinking I might be better off printing it out on a flow chart and re writing it (well some of it).
 
All design methodologies are about breaking down the problem into manageable chunks - where the chunk size is something you can keep in your head. Referring to a document is counter-productive as you lose the "flow" of coding. If you can't understand it, break it down more.

You then have a bunch of chunks that are inter-dependent. A bottom up approach is to build chunks that are not dependent on any others and then move to ones where the dependencies are already built. A top down is to build with assumptions of what the dependent chunks are going to do - and then make those chunks do what you assumed.

So for a typical web app, bottom up is the database bit first, top-down is the web gui first.

You can mix approaches. Some people do the "easy" bits first, some like to do the "hard" bits first.

All development is iterative. You will never have a chunk perfect before moving on to others. Accept this as part of nature.

External factors always play a part. Use "TODO" comments as place-holders when information is incomplete or known to be subject to change.

I haven't used a flow chart in 30 years - BUT if you find they help, then use them. A big issue with all design methodologies is people get hung up on the rules instead of realising they are there to help you. Pick and choose what you need. If you find you are going through the motions or performing what feels like box-ticking exercises, you're doing it wrong - discard the part that's not helping.
 
Last edited:
It depends on what is required.

I've done pretty much all over the years - including tradition, TDD, Pair, Extreme, Agile/Scrum etc....

There is a need to design, however it tends to be an understand of data and volumes so people don't develop and then deliver something that can only do about 1/10th the performance required.
Personally I hate the comment that code for function and then optimisation can sort out the speed. Performance is just as important as a customer deliverable!

Focusing on little blocks can lead you into problems in the bigger picture (including selecting the wrong technology, code driven user experience (!)).

You need the right (read efficient) design with enough information to form a framework for the rest to hang off. TTD can be put around the edges at a high level then added to as the components are added (business>system>integration>unit).

Agile just means you as an engineer don't sit looking at a small component - you see the business and the bigger picture and know how the smaller components relate. That includes business delivery times and cost.

When writing my own hobby code - I'll write three things:
a) pen and paper class designs if needed, and general "reminders" how the code components fit together (calling etc).
b) automated test cases of various levels to exercise the code/hardware
c) a demonstration application

TTD and a demonstration app means you are forced to make things reusable and think about how the code is used.

The demo app allows you to use the code as if it was being used as intended.. including the manual element and how it interacts with other technologies (parallel activities etc). Although you should design this in - sometimes the way the underlying tech works does not behave in the way you expect (or the documentation indicates).

I will flow chart things from a basic level for code I've not seen before - systems-to-systems or classes to classes - on paper if I want to understand how things work.

Automated test code becomes as large or even larger than the deliverable code, so it's important to have an arching form of technical guidance to ensure the pieces fit without constant refactoring due to the component not being fit for purpose!
 
Last edited:
Quite a bit of stuff mentioned here I've never heard of, I had a look at TDD and it seems a bit beyond me but having said that I've had a few ideas to break my code down into more manageable chunks which will help a great deal. My approach to coding has been to just get it working then as far as I'm concerned it's done, move on to next bit. I even wrote some code that I knew would make things more complicated in the long run but it worked so I left it at that, now it has bitten me on the backside. Time to start rewriting.
Going by your replies I take it you guys code for a living ?
 
Try and follow SOLID principles, I have written a lot of large multi-threaded applications and I wouldn't say much of it was very complex and the bits which are are nicely abstracted away from the rest of the system. As others have said, following TDD can really help, even by just forcing you to follow SOLID principles.
 
I wouldn't bother with TDD if you're working on a game, not for the main gameplay stuff anyway. Core engine functions (if you're rolling your own) then yes, maybe, but otherwise, forget it.

Read up on some common patterns....www.gameprogrammingpatterns.com is very good for the core topics, component systems, game loops, command pattern etc.

Then sketch out the core classes on paper, if you're doing an entity component system model, list out the components and systems.

Then start coding.

If you're working on games, you're going to have to hack things to bits and rework them anyway, so it's not worth getting overly precious about 'nice' code.
 
dal said:
Quite a bit of stuff mentioned here I've never heard of, I had a look at TDD and it seems a bit beyond me but having said that I've had a few ideas to break my code down into more manageable chunks which will help a great deal. My approach to coding has been to just get it working then as far as I'm concerned it's done, move on to next bit. I even wrote some code that I knew would make things more complicated in the long run but it worked so I left it at that, now it has bitten me on the backside. Time to start rewriting.
Going by your replies I take it you guys code for a living ?
Click to expand...

TBH TDD :D is very easy and it means that as you write a test method/class you know the functionality will work without having to keep building/running your application.
 
Flow charts? SOLID, TDD? Good grief.. Seems like too much theory work passed down from the uni's imo.

I've always gone on the basis of a proof of concept, then agree on a low level technical specification which agreed by the user or the person that will eventually sign the work off.

Just code.. if it works then it works.. end of.. ?

Ideologists - tut
 
Hmm code for a living.. BSc (Hons) Software Engineering + 18 years in the industry globally :) I did Yourdon, SSADM, OOA/D, and studies of methodologies, Z, formal methods, and formally proven concurrency systems, numeral computation, etc as it was a SE rather than CS degree..

If you've got a large amount of code.. and it's feeling unwieldy then you're starting to see the scaling issue of code (as the number of people vs the code base).

Making a design with a simple pen an paper works, just say "when the user does this ... what happens".

Game coding nowadays is split into (a) those that code ground up and (b) those that simply make use of libraries and tools.

At Uni myself and a flatmate used to write games. Over summer break - I custom wrote a background system that really worked perfectly and efficiently.. leaving lots of CPU time for the next step. Tom on the other hand, re used his library of coded routines to hack together an inefficient example to the point that the code was complete and just the artwork was needed to complete. The result worked but wasn't great (the idea was the entire screen rotated) but did enough to get money in. The Acorn Archimedes ARM3 had less CPU power and the GPU had todo the music, the screen render and the game itself..



In the end I think you may be better looking at the code to use tools and simplify (making the game code smaller and more manageable). It will mean you're not spending so much time writing code for code sake but progressing in developing the ideas you have.
 
Last edited:
Admiral Huddy said:
Ideologists - tut
Click to expand...

^^^ Lowest bidder :D

A programming maxim I like to follow is: Always code as if the person coming after you is a homicidal psychopath who knows where you live.

And to answer the other question: Been paid to be a coder for over 30 years now. Never really did much with games programming though beyond some 6502 assembly code as a youngster. Long forgotten it now.
 
chroniclard said:
Just sit down and start smashing it out.
Click to expand...

This thread is about coding mate :p.


Despite my best intentions I rarely have anything more substantial than a breakdown of functions before I jump in. Mostly keep the rest of it in my head(obviously fails sometimes).

I always do GUI on paper first though :confused:.
 
I find it a lot harder writing stuff on my own - probably because I have to make all the decisions - but I decide my "software architecture" and then go with the "thin slice" approach with top-down or bottom-up.

However, often get side-tracked, write a load of random things I think are quite neat then scrap it all and start again.

I'm using a Trello board for my current project though and trying to stick to "for something to be developed it has to be on that list". Makes me think twice before adding things and going off in tangents.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom