how do u take notes and practice?
hi there, ive recently started to learn c++ through "c++ for dummies, 7 books in 1".
I'm having a rough time, i guess thats normal. i try to read for about 2 hours a day. thats all i can manage atm with a full time job and a girlfriend :)
Was wondering? what do u do in order to take notes and practice? i can write the thing in the book sure. but sometimes i tend to forget and my notes are extremely messy :) any pointers appriciated :)
best regards
I'm having a rough time, i guess thats normal. i try to read for about 2 hours a day. thats all i can manage atm with a full time job and a girlfriend :)
Was wondering? what do u do in order to take notes and practice? i can write the thing in the book sure. but sometimes i tend to forget and my notes are extremely messy :) any pointers appriciated :)
best regards
Becoming a strong programmer takes time. Reading will only get you so far, the best way to get better at programming is by writing your own programs. You learn from your mistakes, go and make mistakes, you'll have to make thousands before you're an expert.
Here's what I did. I don't know if this works for everyone, but it really worked for me.
1) Read a book that describes programming basics (variables, functions, etc). Reread sections until you "get it"
2) Think of a simple program you want to make
3) Try to make it
4) Whenever you need new functionality -- something that you don't know how to do -- google it and figure out how to do it. A "fill in the gaps as you go" kind of a thing.
5) Don't add the new functionality to your program directly. Instead make a smaller test program that does just that new functionality and little else -- just to make sure you can get it working and understand it enough.
6) Once you got it more or less figured out from your test program, put it in your main program
7) Repeat 4-6 until your program is finished
8) Start a new program that is more difficult.
The tricky part is figuring out what's "too hard". You want something that's a little out of reach to push yourself to learn something new, but you don't want it too hard that it's just too much to get a handle on.
For what it's worth, I still more or less do the above to this day, even after over a decade of programming.
1) Read a book that describes programming basics (variables, functions, etc). Reread sections until you "get it"
2) Think of a simple program you want to make
3) Try to make it
4) Whenever you need new functionality -- something that you don't know how to do -- google it and figure out how to do it. A "fill in the gaps as you go" kind of a thing.
5) Don't add the new functionality to your program directly. Instead make a smaller test program that does just that new functionality and little else -- just to make sure you can get it working and understand it enough.
6) Once you got it more or less figured out from your test program, put it in your main program
7) Repeat 4-6 until your program is finished
8) Start a new program that is more difficult.
The tricky part is figuring out what's "too hard". You want something that's a little out of reach to push yourself to learn something new, but you don't want it too hard that it's just too much to get a handle on.
For what it's worth, I still more or less do the above to this day, even after over a decade of programming.
closed account (3hM2Nwbp)
| quirkyusername wrote: |
|---|
| learn from your mistakes |
To learn from your mistakes you'll have to be aware of the mistakes that you're making. Peer reviews on your code makes that a whole lot easier. You can post some code snippits on this site for peer reviews when you feel confident with it, and let the more seasoned programmers point out what could be improved.
Last edited on
This may seem like common sense to some people but keep all of your finished working projects. Even if you have to stuff them into a directory on a secondary HDD that will never be opened again keep as many of them as you can. Try to divide the folders into subjects "Windows Apps", "Boost" and "SDL" as some examples taht should all have seperate folders, if you're using multiple libraries together then make a folder for that. The key is to stay organized.
This is so that you can go back to the smaller projects you worked on and see how you accomplished some task, so commenting your code is always a good idea. A lot of comments in your code explaining what you are doing and why will make code a lot easier to read when you come back to it. This is much faster then having to reread the documentation on every single function that you use, I learned that the hard way while studying the Win32 API.
This is so that you can go back to the smaller projects you worked on and see how you accomplished some task, so commenting your code is always a good idea. A lot of comments in your code explaining what you are doing and why will make code a lot easier to read when you come back to it. This is much faster then having to reread the documentation on every single function that you use, I learned that the hard way while studying the Win32 API.
You can also go back and say "Wow, I sucked!" XD
I remember some of my first programs that had one gigantic main function...and goto's.
I remember some of my first programs that had one gigantic main function...and goto's.
I have a memory of how bad some of my beginner stuff was.
One of my earlier game attempts was with MFC/Classwizard in VS6 (or maybe VS4? It was really really long ago).
It was an RPG with a tile based map. But the thing is I didn't draw it tile based, I prerendered all the level maps and stored them all as huge .bmps.
Then when it came to walking around on the map, I did stuff like this:
This was called every time the player took a step.
I even remember having so many maps that I exceeded the compiler's limit for an else/if chain (I got some "program is too complex" error message). My workaround was to call a separate function on the final else, then start up a new else/if chain in the 2nd function.
The battle code was a mess too. Oh man.
One of my earlier game attempts was with MFC/Classwizard in VS6 (or maybe VS4? It was really really long ago).
It was an RPG with a tile based map. But the thing is I didn't draw it tile based, I prerendered all the level maps and stored them all as huge .bmps.
Then when it came to walking around on the map, I did stuff like this:
|
|
This was called every time the player took a step.
I even remember having so many maps that I exceeded the compiler's limit for an else/if chain (I got some "program is too complex" error message). My workaround was to call a separate function on the final else, then start up a new else/if chain in the 2nd function.
The battle code was a mess too. Oh man.
Last edited on
Hi i suppose i can relate because i am reading the same book. well, c++ for dummies 2009 edition.
I think that when you read, it just goes in and then out again. so you should instead of reading for two hours. read 1 chapter and then practice what you have learnt untill you understand the concepts and everything about it.
Also i found it hard to remember things a while later, (where i have rushed myself) so don't rush yourself take your time. you want to learn it not forget it.
hope it helps.
I think that when you read, it just goes in and then out again. so you should instead of reading for two hours. read 1 chapter and then practice what you have learnt untill you understand the concepts and everything about it.
Also i found it hard to remember things a while later, (where i have rushed myself) so don't rush yourself take your time. you want to learn it not forget it.
hope it helps.
You will never, ever, ever, ever, …, ever stop making mistakes. I took me over a year before I could write a "Hello, world!"-style program from scratch that didn't have a bug in it the first time around. However, for every mistake you make you get that much closer to avoiding it the next time. I finally got to a point wear as I'm writing or reading other's code, I can spot potential bugs before they're compiled and run.
You need to write programs... period. But knowing your stuff, and learning good habits early on will save you a lot of time.
PS: I'm still to this day, surprised when I write a program, and it runs correctly the first time. No joke.
You need to write programs... period. But knowing your stuff, and learning good habits early on will save you a lot of time.
PS: I'm still to this day, surprised when I write a program, and it runs correctly the first time. No joke.
Topic archived. No new replies allowed.