Java Command Based Crash Course Concept

[notmattlythgoe]

WARNING: THIS MAY CAUSE EXPERIENCED PROGRAMMERS TO SHAKE VIOLENTLY IN ANGER

Scenario: Given two hours to teach a group of new programmers how to code their robot using the Java Command Based structure.

Some new programmers will struggle with the concept of writing their own methods in the Subsystem classes. Given the short amount of time what are the thoughts on declaring all of the motors and sensors inside of a Subsystem as public fields. Then accessing them directly from the Commands that need them?

public class Drivetrain extends Subsystem {
	public MotorController left = new Talon(0);
	public MotorController right = new Talon(1);
	public RobotDrive drive = new RobotDrive(left, right);
}

public class DriveCommand extends Command {
	protected void execute() {
		Robot.drive(Robot.oi.joystick);
	}
}

I know this breaks many Java programming standards and should be highly frowned upon by an experienced programmer. But, thoughts and opinions?

[Jon Stratis]

The way I see it, there's the "right" way to do it, and then there's the way someone cocompletely new will best understand it and be able to contribute in a short amount of time. I don't think there's anything wrong with picking the "easiest" way to start with, then as you have time working with the individual students or home-based groups to transition towards the "right" way to do it. Often times, I've found that you can find real, practical examples as you go to highlight why there's a "right" way to do something.

Of course, this only applies to stuff like programming. I'm not going to let a student get off using a tool the wrong way and hurting themselves!

[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.

[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.