It is worth adding that many of Zed’s tips in this LPTHW course is for beginners. It can be baffling for total beginners to load up and IDE, set the environments correctly, become familiar with basics functions and the IDE prompts/auto-functions, as well as learning programming for the first time.
This so why many courses talk about terminal and editor only. Stick to learning code not the IDE. But if you are already familiar with an IDE, and another language, then clearly you’ll benefit from it’s known features whilst learning new languages. For me, @Jharris4854 is not a total beginner and should explore with as few distractions as possible. If this means Netbeans and debugger, go for it!
Ironically, I’m learning Java at present and absolutely avoiding Netbeans/Intellij in favour of Vim/Term2
There maybe better support out there. At the time I learned Java, Netbeans was just the IDE the instructor used. It wasnt even the industry preferred IDE; Eclipse was. But I used Eclipse for learning Android…so I guess to each his own. I wasnt impressed with Netbeans python support but it wasnt meant to be bug free. I found alot of syntax errors and misuse of Exception handling in the .py files after I installed the plugin. The most up to date Python plugin for netbeans was for 8.1. I had 8.2. I didnt think it would make a big difference but it most certainly did.
I’m curious @Jharris4854 when you say “where I have to analyze more the 500 lines its” are you doing the following:
You type in all 500 lines of code.
You run all 500 lines of code 1 time.
You attempt to fix bugs in all 500 lines of code.
If you are then that’s something you should change. I work like this:
I write 2-10 lines of code, whatever is a “runnable chunk”.
I review those lines like I would edit an essay I wrote.
I run the script or some automated test script to confirm my 2-10 lines work.
I then only first the 2-10 lines or possibly others I’d written before, but not 500 lines.
I repeat this until I’ve written all 500 lines, then I review it again and try to clean it up. Sometimes this means I delete it and write it all again simpler.
Let me know how you work. Maybe record it and play it back at high speed.
I do have a bad habit of taking on projects out of my league. My style could use alot of revision. Your book is helping me with alot of that. I use to use debuggers more when Id write most of a program(like when I used Java to write a game-Othello)…some of the code Id google. Then Id follow the debuggers bread crumbs line by line. Since I started this book of yours Ive used Atom as you suggested. Until Exercise 41 where I got stuck. Im using Pycharms now. But I learned coding using the method of writing a paper. Rough draft then revise,revise,revise. That is how I learned to write. (Mississippi has the lowest educational standards in the country- or did at the time I was in high school and college. Maybe this isnt the best way to ‘write a paper’ but tbh, the fact I made it to this point is significantly impressive IMO…lol) Im seeing that isnt the best way when Im just learning. But It is quicker than jumping from one program to the other to run and test. I like the fact debuggers have the python interpreter built in. About the 500 lines: I did that when I was learning Java. Like I said I realize that I should start small then just add to it. Im learning alot about OOP on youtube. This one guy Corey Shaeffer(sp) has explained OOP more clearly than Ive ever heard it before. I realize this book is an exercise book, but I need some theory on OOP bc I never fully grasped it
Alright, well at least you know what you need to improve on. People like to say that you can learn “bad habits” in programming, but it’s really not true. It’s not like playing guitar where if you learn a sequence wrong you actually physically learn it through repetition and then can’t physically undo it easily. Programming is a mental activity so when you have a “bad habit” you just…stop doing it. You aren’t forever tainted, and usually people claiming you have a bad habit are actually just rote repeating some junk trend they heard from other famous programmers. Give them a year and they’ll be ranting about some new thing as the “bad habit”.
So, what you should do now is just … stop doing that. To keep it simple, practice just running your code after every line, even if you know it won’t work. You just write a line, alt-tab to the python window, run it, alt-tab back to code and write more (or fix what you just wrote). That’s pretty much how I code.
I came across a page that runs code line by line. http://pythontutor.com/visualize.html#mode=edit
I think it runs like a debuger. I have yet to use one though so i dont know how it runs. I’ve been running the print(>>>)lines for that. but when it comes to following the ‘flow’, print() doesnt help me.
I just put in some random for loops, dict, and what not, and it helped me see the code run. I dont think i would try ex41 lol, but it may run it.