How do you keep control of a program?
Blitz3D Forums/Blitz3D Programming/How do you keep control of a program?
| ||
| Basically i made a few small changes to my code and now the program doesnt work any more, i cannot understand why as i think i have undone the changes i made but it just goes into a file-reading loop where it says it's finished reading the file a few thousand lines early, but also says the EOF has not been reached. It seems that the program is now too complicated to understand, at least by me, how do you keep control of programs more than a couple of thousand lines long with so many moving parts? |
| ||
| Ok even weirder. I just ctrl+z (undid) all the way back to some edits i tested and they DID work, and it still wont run anymore, how has the program corrupted like this? :/ |
| ||
| When I got the license Blitz3D + Fastlibs, they told me something: Do not think that in 15 days interest a great game, the important thing is perseverance. There were many times I've had to start over, simply because they do not know what the hell is what happens, but as time passes I realize that the biggest mistakes I applied them and not blitz3d. Bear in mind that in some way, the only way to learn programming is programming. |
| ||
| Well IDEAL was a big fail of an idea, i just undid all the changes i'd made even further back in time and then accidentally pressed f5 to run so it overwrote the file and unlike the normal blitz editor it doesnt save backup files. So thats about two days worth of progress gone in a puff of smoke :/ I'll go back to normal blitz editor i think, at least it backs up! |
| ||
| Oh and of course, when it ran it didnt work then either :/ |
| ||
| IDEal automatic backup settings are controlled from Settings->Preferences->Backup. Unlike the normal Blitz editor (which seriously, is useless), it does save backup files. Do yourself a big favour and stick with IDEal. It will help you in the long run; especially now you've revealed you're writing projects that are far too large to realistically control with the default editor. To organise a project easily you need to 1) plan carefully and 2) keep to some strict conventions. 2) first, because it's simpler: - declare all of your variables (in IDEal, turn on Strict mode and weld the button down) - avoid the temptation to make things Global - use long descriptive names (this is why you need an IDE with Autocomplete) - give every code module a unique Module Prefix and attach it to all top-level names - learn to use Types, if you haven't already, because you can't work without them - use as many code files as you have code modules, because disk space is cheaper than your time - give each module a defined set of "interface" functions, and don't let other "outer" modules access it in any other way, to control what happens - don't let "outer" modules access "child" modules by bypassing their "parent" - break up any module bigger than a thousand lines into components and treat the old one as a composed interface - break up any function longer than 50 lines (and stick to this hard) 1) is a habit you have to learn to like. Your best friend as a programmer is pen and paper, and it's where you need to get used to doing 90% of your work. (Alternatively, some kind of planner app, but I don't bother with those myself.) Coding itself is a formality; the work of designing an application is a separate step that comes first. Although it'll take some time (initially you'll make many mistakes without constantly testing the code) it'll speed you up enormously in the long run as you learn to separate the logical structure from the words of the program source. Once you start drawing out the program logic, you'll be able to see how the various procedures interact; this "high-level" view of the design makes it easier to see how you can refactor code so that it doesn't depend on other areas, or only accesses them through a predefined interface. This keeps organisation strong. The eventual goal is that you shouldn't have many moving parts interacting with each other; just a tree of code blocks spreading outwards from the main program, interacting through the clearly-defined, impenetrable interfaces that guarantee safe access. The best I can do is recommend that you read books on the subject. The Structure and Interpretation of Computer Programs is widely regarded as the finest textbook on computer science in the world, and focuses heavily on how to compose complex procedures and data structures out of simpler units; I'd also recommend Object-Oriented Programming with ANSI C as it gives a good example of how to structure code according to higher-level principles in a non-OO language (Blitz3D being one such). Applied Object-Based Programming with Blitz3D is less in-depth, but does focus on Blitz3D itself, which is an advantage. All of these (and many others) are free to read online in their entirety. Last edited 2011 |
| ||
| . (double post) Last edited 2011 |
| ||
| In preferences of Ideal you can set automatic backup on/off. It's a good habit of saving your work with different version-numbers, after a few changes. (prog1.1 prog2.4 etc.) Also try to program your code as modular as possible. So if you want to change something, you don't have to make changes all over the place. (also reduces errors by typos) [/edit] Do as Yasha said ;)...dang; he is fast.. [/end edit] Last edited 2011 Last edited 2011 |
| ||
| First of all: use functions, and place those functions in .bb files and use Include to include them into the main program. Next, ensure that each function fits onto a single page in your editor. If it gets bigger than that, split the function up in two pieces. It seems like an arbitrary rule, but it works fine. It helps keeping a clear overview of each function. Edit: Oh yes, and create a project folder, containing all these include files. Each time you want to implement something new, or change something, first of all create a copy of this folder. It is a rather blunt and primitive way of versioning, but it does the job. Last edited 2011 |
| ||
| IDEal automatic backup settings are controlled from Settings->Preferences->Backup. Unlike the normal Blitz editor (which seriously, is useless), it does save backup files. Do yourself a big favour and stick with IDEal. It will help you in the long run; especially now you've revealed you're writing projects that are far too large to realistically control with the default editor. To organise a project easily you need to 1) plan carefully and 2) keep to some strict conventions. 2) first, because it's simpler: - declare all of your variables (in IDEal, turn on Strict mode and weld the button down) - avoid the temptation to make things Global - use long descriptive names (this is why you need an IDE with Autocomplete) - give every code module a unique Module Prefix and attach it to all top-level names - learn to use Types, if you haven't already, because you can't work without them - use as many code files as you have code modules, because disk space is cheaper than your time - give each module a defined set of "interface" functions, and don't let other "outer" modules access it in any other way, to control what happens - don't let "outer" modules access "child" modules by bypassing their "parent" - break up any module bigger than a thousand lines into components and treat the old one as a composed interface - break up any function longer than 50 lines (and stick to this hard) 1) is a habit you have to learn to like. Your best friend as a programmer is pen and paper, and it's where you need to get used to doing 90% of your work. (Alternatively, some kind of planner app, but I don't bother with those myself.) Coding itself is a formality; the work of designing an application is a separate step that comes first. Although it'll take some time (initially you'll make many mistakes without constantly testing the code) it'll speed you up enormously in the long run as you learn to separate the logical structure from the words of the program source. Once you start drawing out the program logic, you'll be able to see how the various procedures interact; this "high-level" view of the design makes it easier to see how you can refactor code so that it doesn't depend on other areas, or only accesses them through a predefined interface. This keeps organisation strong. The eventual goal is that you shouldn't have many moving parts interacting with each other; just a tree of code blocks spreading outwards from the main program, interacting through the clearly-defined, impenetrable interfaces that guarantee safe access. The best I can do is recommend that you read books on the subject. The Structure and Interpretation of Computer Programs is widely regarded as the finest textbook on computer science in the world, and focuses heavily on how to compose complex procedures and data structures out of simpler units; I'd also recommend Object-Oriented Programming with ANSI C as it gives a good example of how to structure code according to higher-level principles in a non-OO language (Blitz3D being one such). Applied Object-Based Programming with Blitz3D is less in-depth, but does focus on Blitz3D itself, which is an advantage. All of these (and many others) are free to read online in their entirety. Word wise. I'll never be a skilled programmer, always a fan. |
| ||
| How do I download the book in pdf and put it to a USB? |
| ||
| Well, some of you might not agree with me here, but I prefer not to use include files. The reason why is: I easily lose control over the lot of include files, eg. when I backup the source, or port it to an other machine ("Include File not found is very C++-ish"). I like the one "Program one Sourcecode" style. But this is really a personal matter and it depends on the editor that is in use. Function folding is very useful and allows a huge program to be handled easily. What is more important to me is good Naming and good Remarks and incode- documentation. For example parameter descriptions in every functions header. There should be one main loop, calling functions of an average size. You don't need a function for every 3 lines of code, but functions should also not be too big, so you're not lost in a function because it seems to be endless. Each section of the mainloop should be remarked well. There should be sections for things like: input handler, item update, collsion, rendering etc. In the source you may place some big markers, so you see it when you scroll, eg: ; ************************************************************ ; ************************************************************ ; ************************************************************ ; ************************************************************ ; ************************************************************ ; ************************************************************ ; ************************************************************ ; don't miss this Although I think in many 3. party editors there are much better functions to run your program inside your head, in a simple editor like the original one such markers are really useful. Just like huge gaps of empty space between the functions. But I think you also have problems with debugging and your backup system isn't solid. Learn to isolate Problems. Where does the error occur? You have to be able to locate, isolate and identify any problem, at any time. It is possible and was discussed here already. As a simple and save backup system I'd suggest to select your sourcecode (again, if it's only one file :) then this is much easier) in the explorer window, then hit Ctrl-C, then Ctrl-V, there it is, your backup file. Do this whenever you just passed a certain milestone with your sourcecode, eg. when you've fixed a problem and everything works well after some tests. This way you can handle rather long sourcecodes. I am sometimes am working with 12'000 lines even in the original editor. |
| ||
| Well, some of you might not agree with me here, but I prefer not to use include files. I don't agree. Magicville had more than 30,000 lines of code across about ~140 includes. Trying to manage that amount of code in a single file would be a complete nightmare. Plus, it allows me to keep everything modular - write a bit of code, tweak it so its perfect, close the file, never look at it again. Job done. |
| ||
| Trying to manage that amount of code in a single file would be a complete nightmare well, to you maybe. But to me it would be a nightmare to handle 140 include files. When an editor allows function folding, as well as to open multiple simultanous windows (of the same file) then I don't see a problem. Of course, the editor should be fast enough, for scrolling etc. I know they say "do modules, do structured programming" etc. but back in time when programmers were godlike gurus, there was a dispute about the true benefit of "structured programming", or what some people like Nick Wirth meant with the term. Some say it usually means "we want to be able to kick the programmer as soon as he did the work and then maintain the code with some kind of cheap mechanic". This might have been the time when programming was taken out of the hands of artists and given to an institutionalized lobby that attempted to in- and exclude people from academic carreers, depending on their political attitude - wait a minute, it's getting off topic :). Well nevertheless it's about structured programming. I do suggest to use a certain structure, and if you want to apply for a job as a programmer you certainly should follow the official guidelines. But for Bedroom Coder Incs I'd also suggest to use the structure that fits best your needs. |
| ||
| All you need blitz3d offers, it really means is that agility is achieved blitz3d. You can have a single file with 50,000 lines of code this for me would be a nightmare, but if the basis is the ideal editor, the includes are a great option for large projects. I think the key here is how we face against blitz3d, and each develops a unique way of doing things. |
| ||
| Hello. I think, in the first instance, black box programming is probably the most important method you can follow. It allows you to structure your programs at a high level, ideally write once and then forget about and, most importantly, allows you to test and ensure you get the correct values out for given input. While that might sound simplistic, it works. As for editor preferences I think it's a case of use whatever works for you. In work I use VS 2008 (moving onto 2010 soon, whoop!) but at home tend to use the standard blitz IDEs - they work for me. Then again, I cut my teeth on a c64 and later wordstar and emacs - so think yourself lucky you've got a choice :) Goodbue. |
| ||
| this every time is more difficult, perhaps one day when a real programmer blitz3d want to switch to another language, I began to try to make a cube with C + + and directX and I prefer for the moment the command createcube of blitz3d, I see no need to recreate the wheel when this is already done. That's when, not because others want you to go to C + +, I'm just a fan of this. |
| ||
| Well IDEAL was a big fail of an idea, i just undid all the changes i'd made even further back in time and then accidentally pressed f5 to run so it overwrote the file and unlike the normal blitz editor it doesnt save backup files. So thats about two days worth of progress gone in a puff of smoke :/ Do you use Windows 7? If so, you can right-click on a file/folder and select 'Restore Previous Version'. You'll get a list of all previous versions that are automatically saved courtesy of the restore points.Vista may also have this functionality, I don't know. |
| ||
| A good worker does not depend on the tools you use, if you have the agility to handle. Eventually we have to control the hammer to hit us no time to try to put a wood nail. I think the success of this depends largely on how much you are willing to give to understand that if basic programming becomes more complicated in other tools is a nightmare when he lacks expertise. |
| ||
| I really like the original Blitz3d IDE , it's comfortable like a pair of well-worn slippers. I've tried a few other ones but didn't like them much. The only thing I don't like about the B3D IDE is that the undo function is rubbish. |
| ||
| One of the many things I like the ideal editor is that you can group all the files in a single project. Something like development environment. net. Therefore the program into modules is equivalent to putting up a wall like you do with bricks, which over the long term benefits far in the maintenance and development of the program. |
| ||
| A good worker does not depend on the tools you use, if you have the agility to handle. Eventually we have to control the hammer to hit us no time to try to put a wood nail. *sincere applause* :D |
| ||
| Thanks for the tips, but now, I'm practically ready to give up on blitz all together as a simple bit of code will not working, in fact its breaking the files it's supposed to handle. Quite simply it comes down to this (where filein is a valid file which has been written to before): extra$="<Explosion>Vehicle</Explosion>" WriteLine(filein,extra$) This will NOT write the string to the file, this will make the program IGNORE the addition of extra$, write the next line and then skip a line and a half before starting to write again. This MUST be some sort of bug because: * EXTRA$ is a string which is made from other parts, but IS as above when the error occurs. * When the WRITELINE command is censored the rest of the program works flawlessly. * The EXTRA$ variable is not referenced at any other point, its not a global its a specially created variable just to handle this one thing. * Take this code out of the file and it works perfectly, when in, it screws up. I've tested this for a few hours and can think of no other thing to test. Its the writeline command which is ruining all of it and that doesnt make any sense at all as the line it writes is basically a one-off addition to the file. |
| ||
| This is just a hunch (since it's based on the variable name), but you're writing to a file you've named "filein" - did you open it for reading, for writing, or both? If you opened the file as read-only, write commands will fail. Failing that... have you checked that the file is still open? EDIT: Which was a stupid suggestion if you're successfully writing to the file on both sides of the command... sorry. Still, is it the same file handle, or did you copy/paste that line from a different section of code where you were using a read-only file? Last edited 2011 |
| ||
| I would recommend starting a new thread for this problem. It kinda drifts towards something completely else now. It aren't these lines which are causing the problem. They work fine: ff = OpenFile("test.txt")
WriteLine ff, "line1"
extra$="<Explosion>Vehicle</Explosion>"
WriteLine(ff,extra$)
WriteLine ff, "line2"
CloseFile ffAre you using OpenFile and SeekFile to access the file? In that case, you need to ensure that WriteLine doesn't overwrite EOL characters chr$(0). I would start a new thread and post some more code (ie. from ReadFile to CloseFile). |
| ||
| It's the same file, it's opened for writing to. but yes its possibly a slightly confusing name for it. It's the same file handle and command which has worked on every other line of the file. In essence what I am trying to do with the code is make a Backup of a file, then copy every line across and insert this line at a particular point. It's really a great great deal more complicated than that, with the other lines perhaps getting changed as well, but as i say, the WRITE command works elsewhere, and the EXTRA$ string has been invented for this one function and this one purpose. |
| ||
| The reason I ask is that large projects can sometimes have a problem that causes the debug information to "slip" away from the actual line of the error: http://www.blitzbasic.com/Community/posts.php?topic=91532 It's caused by problems with copy and paste, and is easily corrected as per the linked thread. Anyway, you said your project was some thousands of lines long - if the "slipping" effect has happened to your files, and you're using the debug console to find out where the error is, you may actually be getting pointed towards a completely innocuous line, two or three lines above the real error. EDIT: Once again... a stupid suggestion, since you already said you tried commenting out the line. Not on the ball today, am I? I think we'll need to see some more code to have any more helpful suggestions, sadly. That command works fine in isolation, as you can see. Last edited 2011 |
| ||
| Ok here is the link to a download: https://docs.google.com/leaf?id=0B5-Yd6LiksJ4NzhjNDE2MDQtYTEwOC00ZDAxLThlMGYtNmQ4NjMwNWEyMGRi&hl=en&authkey=CMqQ1aIM you'll want to install this in c:\games\your_faction\*.* or re-run the processes in SETUP from the main program. ALSO you wont want to "compile and run" as that might cause a few difficulties, just hit SAVE ALL CHANGES from the main menu. Basically, RFG_Tools is the main file. The others are just includes, and bear in mind this is a stripped down version. The problem happens during the COMPILE function which compiles all changed variables back up and adds the changes in as the lines of code from the xtbl files are read from a backup file to the new file. I got the program to take the <explosion> tag out of the "charge_placer" section of the xtbl file, but it all goes wrong when trying to make it re-add an explosion line to that section if there isnt one there. During testing of this you will most likely corrupt the weapons.xtbl file so just run the BAT file in the misc-active directory and it will re-create it. So basically it's supposed to insert the <explosion> tag from the charge placer section when you select an option for the charge_placer explosion in the program, so when it hits the end of the charge placer section and finds: </weapon> it should be adding <Explosion>[whatever explosion selected]</Explosion> BEFORE inserting that on the next line. But this is where it starts corrupting for no reason i can see. I made the program report the line before writing it to the file (see value "shufty$" or "Holy Smokes") it reports the correct thing, but then the writeline just below that just... does its own thing. |
| ||
Dude!fileout=WriteFile(RFGT_Dir$+"_misc_active\"+file$) filein=ReadFile(RFGT_Dir$+"_misc_active\temp.xtbl") "filein" is a read-only file! You can't write to it... I don't have a very good handle on the rest of the code, not least because I can't actually run it as Red Faction isn't installed (it just hangs by the way - you might want to give it an error or some clean way to abort if it can't find Red Faction), but yeah, you can't WriteLine to a file opened for reading only. To both read and write, you need to use OpenFile. I haven't checked to see what you're doing precisely, but using WriteFile and ReadFile on the same file doesn't make it read-and-write, it makes two separate handles, with separate permissions (and almost certainly doesn't work at all, because files aren't meant to be used that way). Also, are you aware that filein is a global, even though you're using it like a local? That may cause you some grief in the long run if you aren't careful. Irrelevant here though. Last edited 2011 |
| ||
| Ahh i changed it to fileout for the writing and it now INSERTS the line of coding... however after the </weapon> section it still misses out 1.5 lines which it should just be copying so something there is really messing it up somehow. I'll try and use totally new variables in that function where possible and hope that stops it. |
| ||
| EDIT: Never mind, found the backup file! It's extremely funny in an ironic way that ideal wont open the backups its saved!! I have a version which now seems to work, i have no idea why but im not gonna push my luck by attempting to find out. Last edited 2011 |
| ||
| I think you should find it out. |
| ||
| I tried that once and nearly lost the file with the mystery working code, besides notepad++ hasnt brought up anything major between a working and a not working version, besides the fact that after inserting the additional line of code into the FILEOUT stream, i asked it to show me what it was outputting by printing the next ten lines to the screen i cant see anything that would effect it. |
| ||
| i asked it to show me what it was outputting by printing the next ten lines to the screen Straight from the stream? Thus rendering them unavailable to the rest of the program? (As a guess) Last edited 2011 |
   |