NOTES
I used a fair bit of time yesterday tracking down a bug and in my non-mindful state, I changed a few things but I'm not entirely sure where. I did add some comments to help me track them down. The bug was having a global smart pointer. I know that doing so is bad but I needed some temporary code to test some ideas. Looking back, sticking with clean code would have been the better way to go.
I cleaned up my debug code but now I've got crashes happening in different random locations each time.
I added a bunch of asserts before each place I had runtime crashes. The program now runs but I get a segmentation fault when I exit.
Worse, they're happening at different locations.
I don't like when I have to debug by turning things on and off instead of using the debugger.
I tried exiting right after initializing and skipping the updating. Same crash.
9:15 PM
Turning things on and off. Getting closer.
10:47 PM
Still going...
11:28 PM
I had a vector of about size 4 and I was overwriting a value outside the range of that vector.
11:35 PM
That was it. I thought there would have been an error message if I tried accessing something outside of the vector. There wasn't.
As I was working I thought I'd get a start on writing something I've been thinking about.
BINH'S PROGRAMMING RULES
+ Add a comment when a block of code is more than one line.
+ Avoid global variables
+ Avoid macros
+ Avoid compiler directives
+ Use const as much as possible
+ Use smart pointers
+ Prefer composition over inheritance
+ Avoid function overloading
+ Avoid inheritance
+ Inheritance from from an abstract interface class is okay
+ (That line about inheritance...)
+ Don't get fancy with your use of abstract interfaces (elaborate)
+ Use variables instead of values when calling functions
+ Keep your functions less than 80 lines wide
+ Keep your functions less than 60 lines. The key thing is to be able to see your function without having to scroll.
+ Keep your implementation files less than 2000 lines.
+ Forward declare your classes as much as possible, expect for container classes
+ Only "#include" in your implementation files as much as possible.
+ Only use the key word "using" in your implementation files.
+ Develop a way to change variables without having to re-compile, and better, without having to re-start your program.
+ Keep a copy of all of your code.
+ Keep an eye on your compile, link, and start-up times.
+ Give yourself at least two months to get up to speed on new programming languages, libraries, and tools.
+ Write down and share things that took you a while to figure out.
+ Don't do anything in your constructor. Do it all in an Init() method.
+ Avoid down casting
+ Attend to all compiler warning messages
+ Use variables instead of values in selection, loop, and calculation code.
+ Keep your list of debug and "to do" markers at size 0
+ Don't use more than 1 level of nesting
+ Avoid using words that you use as markers in comments, variable names, and function names, class names, etc. Words such as "debug", "test", "new", etc
+ Keep your changes small and un-doable. Undoing a change that took you from a working program to a broken program is easier than figuring out how to fix a broken program.
+ Keeping clean code clean is easier than cleaning dirty code.
+ Don't go dark. Keep your stakeholders up to date
+ If you have trouble starting, figure out a way to warm up that works for you
+ Have a way of tracking how long things took
+ Figure out the amount of time you can comfortable focus and focus
+ Take at least a minute break every thirty minutes
+ Avoid energy drinks
+ Try to stay in the sweet spot of arousal
+ Avoid getting into debugging frenzies
+ Finish projects before starting new ones. You don't have to finish them well, but you have to finish them.
+ Keep morale up by going after the seemingly easy goal first and then build off that.
+ Release often.
+ Doxygen your code.
+ Make note of code that you're proud of
+ Endeavor to write beautiful code
+ Look for ways to automate the boring parts
+ Avoid doing the same things
+ My belief is that the best documentation is written by people learning to use something new. In addition, Writing documentation as you're experimenting helps you to be methodical.
+ Develop a way to feel the excitement that you felt when your first started the project.
+ Develop your strength and flexibility to avoid repetitive stress injuries.
COMPLETED ACTIONS
* Fix debug code
* Removed a few global smart pointer variables
* Fixed mysterious segmentation error. I was overwriting some memory by accessing areas outside of a vector.
NEXT ACTIONS
* Check out http://www.drclay.com/
* Remove global smart pointer variables
* Remove global variables
* Remove class PhysicsInterface
* Remove class PhysicsGraphics
* Convert image into format that the neural network can use.
* Connect view port to agent vision input.
* Round to the nearest integer in the CaptureViewport() code.
* Re-examine angular and linear deceleration code.
* Consider always applying a deceleration force.
* Enable displaying the mouse pointer when running the simulation.
* Add food
* Re-enable serialization.
* Get agent populations surviving again.
* Have a neuron for rotating left and another neuron for rotating right.
* Have a neuron for moving forwards and another neuron for moving backwards.
* Add code to reset a cube that is not on its "feet".
* Increase heights of walls.
* Get shadows working properly.
* Implement command controls.
* Implement FPS controls.
* Re-enable communication.
* Conduct gender experiments.
* Conduct maturation experiment.
* Experiment with joints and more advanced body shapes.
* Make the graphics look more like the demos in Bullet.
* Display frames per second
* Implement a way to use the mouse to re-size the viewports.
* Implement a way to use the mouse to re-position the viewports.
* Implement a way to use the mouse to move a screen like on an iPhone.
* Implement off-screen rendering.
No comments:
Post a Comment