Anybody knows guys is there a possibility to trace a code in Netlogo statement by statement, like using F7 or F8 in C/C++,...
-
2[This](https://stackoverflow.com/questions/32204386/netlogo-debugging) should address your question! – Matteo Nov 14 '21 at 19:25
-
Does this answer your question? [NetLogo Debugging](https://stackoverflow.com/questions/32204386/netlogo-debugging) – Seth Tisue Nov 23 '21 at 00:34
1 Answers
Generic longer comment:
/* So as the comments above say, there is not a debugger but there are work-arounds.
Replayable random-seeds and many print statements help. I define v-print routine to print if a "verbose" switch is TRUE, so I can put in lots of v-print statements, sometimes one per line of code, but shut them all off until needed with one interface switch.
For many Netlogo users, judging by the questions, this is the first programming language they have ever used. So there is some generic advice like "take small steps and do sanity checks often, expecting that something will go wrong."
But maybe the best and hardest advice is to learn enough Git and GitHub to set up a repository and "SAVE COMMENTED VERSIONS OFTEN", because otherwise it is a losing proposition to try to debug tangled code with multiple errors that you have been trying random changes on to see if they help. Some times you need to fall back to the prior last-good version and work forward from there again step by step looking for where it breaks. Working forward is easy. Debugging backwards is hard.
Debugging code with one error is much easier than debugging code with multiple errors.
Decades ago I used to repair analog televisions. I loved rich people because they called as soon as one thing was wrong. Poor people waited until the set was full of errors then called. I've seen similar behavior in programmers continuing to code hoping that prior errors will somehow magically go away. Slow is fast.
GitHub has been a life-saver a few times when I accidentally deleted a section of code in the editor and didn't notice I'd done it. It's easy to have lines of code highlighted and then type a word while not looking at the screen. Then you go crazy with code that worked yesterday and doesn't work today and you "didn't change anything".
Using GitHub to restore a prior version, or simply doing a differences ( "diff" ) between the current version and prior version shows what changed.
*/

- 1,455
- 1
- 8
- 9