What could one do every day to get him motivated to code ?

[TI-994A]

But really, you should just jump into a project knee deep even if you don't have it planned out completely...

Clearly your forte, Warmonger.

Hi Primoz128. Whatever the approach, I truly believe that there must be some element of planning. Jumping in blindly would only result in atrociously buggy code, and perhaps a less than useful app. Even if we don't pore over storyboards and flowcharts, we'd still need a mental roadmap of the intended solution. With that, we could break the project into smaller and more manageable modules, which would individually take less time to complete. When we keep hitting them out of the ballpark, chances are we're less likely to get bogged down.

[idle]

Sometimes just coding is the way to go, you can't plan what you don't know!
Start on what you do, work out what you don't!

[Warmonger]

But really, you should just jump into a project knee deep even if you don't have it planned out completely...

Clearly your forte, Warmonger.

Hi Primoz128. Whatever the approach, I truly believe that there must be some element of planning. Jumping in blindly would only result in atrociously buggy code, and perhaps a less than useful app. Even if we don't pore over storyboards and flowcharts, we'd still need a mental roadmap of the intended solution. With that, we could break the project into smaller and more manageable modules, which would individually take less time to complete. When we keep hitting them out of the ballpark, chances are we're less likely to get bogged down.

If you know how to code then there isn't really a planning stage for any project. Some of the biggest and best programs in the world are not exactly "planned". Even games like Darkfall Online was not planned, four guys quit their jobs and wrote the game in their basement. The best way to tackle a project is to immediately start coding, and come up with ideas as you go. Yes you must have a basic understanding of what you're writing in the first place. But more or less that's just "what" you plan on making. Earlier today I said I wanted to write my own cross-platform multi-protocol messenger. As soon as I did I started coding functions for the MSN protocol. You simply cannot plan out every single piece of code beforehand. Code in the basic functionality first, and work on the more complex stuff later. Source code is source code, you can always go back and fix it up later! I for one get the best ideas while im coding something, because as I read through the code. I spot places where advanced functionality can be programmed in. And I take advantage of that. Most desktop applications shouldn't take you any longer then a couple of days to a couple of weeks to code. So in my opinion the planning process is just time burning on the clock.

[marc_256]

Hi Primoz128,

My 3D CAD/CAM/CAE/CNC project is about 1.637.500 lines long,
40% is code, 60% is data section.

Sometimes I give up, and leave it for what is is for a few days.
The most important thing is my goal.
After some days I feel it again, and then I continue my software.

- I have 2 PC's to work with, in two different places. it changes my mind.
- I installed recently a LAN network, so I can work on different places.
- I make drawings of my windows, and GUI interfaces (on insides of pizza boxes) .
- I make flow charts of my programs (1 big overall flow chart) and than detailed flow charts.
- I read books and internet to find solutions for the problems and algorithms I need.
- And I make little parts of the large program (easy to test and debug).

But the most difficult is to find the energy to continue after a big problem...
I recently had a HDD failure and lost 10% of my work (days and days of work).
So I had to redo all my work.

Marc,

DO NOT GIVE UP ...

[Primoz128]

I started my game with the immediate coding after few days of planning what i want, and the result after few months of here and then work in school year and later 2 months in holidays a lot, well result was in the end too much complications, even though i hardly formated, commented etc, it fell into bugy codes, codes totaly in wrong sections etc... i made inventory for it after half a year, now im gona put everything to maximum organised way, and into scripts stuff that repeats million times, probably gona reduce 3000 + lines of code into 2000 +...

I guess i had the first start for 2 months + 1 - 2 months when at school of working withought care of anything else, cause by following the book i made dozen of great games... lost motivation afterwards since i fell into bugy stuff, complications etc, and lack of progress...

[marc_256]

I learned programming with the assembly language (6502 cpu).
There you need to comment almost every line of code.
After a few mounts you do not understand your own program anymore.

This is still what I do, I COMMENT ALMOST EVERY LINE OF CODE even in PB.

So I can find my way of programming after years.

Yes, it is a lot of work, and is very slow by creating a program.
But when you need some changes after some time, is works mush, mush faster.
And at least, you understand yourself

Marc,

[TI-994A]

This is still what I do, I COMMENT ALMOST EVERY LINE OF CODE even in PB.

Hi Marc. You're absolutely right! Comment your code religiously.

[c4s]

I COMMENT ALMOST EVERY LINE OF CODE

I hope you don't do something like this:

Code: Select all

If A = 1  ; If variable A is '1'...
  String$ = "test"  ; ...assign text "test" to the variable String$
EndIf  ; End part for: If variable A is '1'

...because it's wrong.

I've seen code where the obvious was explained numerous times. Only comment code which isn't obvious on the first look! Otherwise it's much harder to spot important code parts and you'll loose the general overview.

[TI-994A]

Code: Select all

If A = 1  ; If variable A is '1'...
  String$ = "test"  ; ...assign text "test" to the variable String$
EndIf  ; End part for: If variable A is '1'

Hi c4s. I don't see any reason for such code comments, unless you're unfamiliar with the syntax. But if you can't recognise simple variable assignments and conditional statements, then you shouldn't be coding. (and when I say "you" I don't mean you)

The comment in brackets is a good example.

[c4s]

@TI-994A
When you both say that you're commenting (nearly) every line of code, I'm thinking of something along the lines. I've even seen such code on the forum so I just wanted to point out that commenting too much is bad as well...

[BorisTheOld]

If you know how to code then there isn't really a planning stage for any project........... Most desktop applications shouldn't take you any longer then a couple of days to a couple of weeks to code. So in my opinion the planning process is just time burning on the clock.

Rubbish!

[Primoz128]

Ye those kind of commenting are more complicated than the code xD.

[Polo]

When I have a project in mind, I usually write some kind of todo list on a piece of paper, and start straight away in the order of that todo list (which, obviously, gets bigger when the project move forward). Other than that I don't do any planning or anything as I usually know where I want to go
It's probably not the best approach but it works for me!

[IdeasVacuum]

Planning/Scheduling requirements are dependent on how much time you have - if you are working on a commercial project for another company, then a schedule is essential, especially if you want to make a profit!

It's very important to plan - design the GUI and decide what features are essential for the app, ease of use etc. Appearance - you may need to match your customer's "corporate theme" which may or may not need custom gadgets to achieve (extra work!). Once you have an overall design on paper (or virtual paper), then you can make-up your schedule.

Top of the list is the form design, especially if you have a customer who will be inquiring progress - they can see progress in the GUI layout without necessarily understanding any code. You can then get the customer to commit to the design before heavy coding, so if they change their minds later you can charge them for the extra work that the change entails. If you are not organized in this way, you would probably end up making a loss at best - you will also lose out on future work because you couldn't deliver within a reasonable time......

Being organized is motivational because you have a project consisting of several milestones - there is a sense of achievement as you progress and you know how much work remains to be done at any stage.

[marc_256]

For those who are not agree with me !!
about commenting your program in detail ...

1) What if you work in a team development, and the others need integrate there stuff in your program ?

2) What, one day you like to OPEN SOURCE your program ?


? is 'commenting' good english ??

Marc,