Java Command Based Crash Course Concept

[notmattlythgoe]

Originally Posted by GeeTwo

It's a easier to never pick up a bad habit than to break it.

If you want to have a victory in two hours, it would be better to have a working set of conventional code and have the prospective programmers make mods, extensions, or minor corrections. That's how most programs are actually written, anyway.

The problem is, these are not my kids. When I leave they're on their own to code their robots for the season. They need the ability to write them from scratch.

[GeeTwo]

Originally Posted by notmattlythgoe

The problem is, these are not my kids. When I leave they're on their own to code their robots for the season. They need the ability to write them from scratch.

I don't believe that any our four robots' code was written from scratch. We have started with a "barebones" program that has a similar drive system to ours, then start adding on our particular design choices. This is actually a design decision that we usually do after the high-level design solidifies: what code base shall we start from? For Recycle Rush, we started with our own 2013 code, which had a tank style drive. For Aerial Assist, we started with a generic mecanum robot code from the internet. I was not involved in programming our first two years, but I'm confident Gixxy also started with working code rather than trying to write a robot "from scratch".

[JesseK]

Tough to debug - the 'set' methods allow you to put breakpoints to figure out what code is causing change. This is particularly important in multi-threaded code. At the same time, I rarely actually put breakpoints in simple 'set' methods as a veteran.

Make the member variables immutable with the 'final' keyword and use the variables directly. Then it's fine from a pragmatic perspective. Grumpy people will argue about style, but whatever. I mean, it's not as bad as javascript, where anything can change anything, and you can pass a variable in where a functor should be and nothing stops you until it blows up 10 calls into the stack...

[notmattlythgoe]

Originally Posted by JesseK

Tough to debug - the 'set' methods allow you to put breakpoints to figure out what code is causing change. This is particularly important in multi-threaded code. At the same time, I rarely actually put breakpoints in simple 'set' methods as a veteran.

Make the member variables immutable with the 'final' keyword and use the variables directly. Then it's fine from a pragmatic perspective. Grumpy people will argue about style, but whatever. I mean, it's not as bad as javascript, where anything can change anything, and you can pass a variable in where a functor should be and nothing stops you until it blows up 10 calls into the stack...

Good call on making them final Jesse.

I think this process will take one confusing step out of the equation for new programmers and teams without programming support and hopefully give them the ability to quickly get a robot up and running.