![]() |
Java Command Based Crash Course Concept
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? Code:
public class Drivetrain extends Subsystem {Code:
public class DriveCommand extends Command { |
Re: Java Command Based Crash Course Concept
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! |
Re: Java Command Based Crash Course Concept
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. |
Re: Java Command Based Crash Course Concept
Quote:
|
Re: Java Command Based Crash Course Concept
Quote:
|
Re: Java Command Based Crash Course Concept
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... |
Re: Java Command Based Crash Course Concept
Quote:
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. |
| All times are GMT -5. The time now is 10:16. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi