Quote:
Originally Posted by faust1706
Year after year, the vast majority of teams are writing poorly written, inefficient, and disorganized code. Their code base fails to generalize for multiple years due to poor design, but no one seems to care or talk about this.
Someone posts a cad drawing of a robot that they did for practice. People ask questions asking about the foundations of the design ("How thick is the G10?"), but no one asks questions when code is released. No one asks, "what is the *big-O notation of this function?" No one cares enough to truly scrutinize someone else's code. No one cares that an on board vision program isn't threaded. No one cares about how inefficient a routine is so long as it works in a match. A lot of teams forbid the altering of code once it works, which is a disgusting practice. Teams that get 10-15 fps on a vision program and say "it's good enough" when they haven't even done their research on optimization techniques. The vast majority of code would get a 'C' at best in an intro to programming class in a high school. So why is no one talking about this?
|
I agree there's a lot of poor quality code in FRC and little higher-level discussion. I think there are many reasons for this, some of which have already been mentioned.
-A lot of high schoolers do poorly with programming: Even though the AP computer science test is ridiculously easy over 30% of students who took it last year received a 1 (for those not familiar with AP tests, 1 is the lowest possible grade). And out of all the AP tests given that was the highest percentage of ones awarded.
-Reading code is not very fun. I know you've released a couple of interesting projects and it's cool to know what they do but I'm pretty much not going to read their source code unless I want to reuse them.
-The code libraries that you're given in FRC don't set you up to do fancy things well. It's non-modular in a way that makes unit testing hard. It's hard enough that I don't think I would have figured out a way to do it when I was in high school. Sure there are teams that have worked around this and built things that you could build on, but they're not well known. For example, my team publishes our code which includes a very different way of using C++ but I don't know of any other team that's even looked closely at it. Similarly, 1510 has published an alternate framework for Java which they've been using but I only know of one other team that has bothered to try it.
-Optimization and efficiency are ignored because they can be. To do what the average team does the processor is about two orders of magnitude faster than it needs to be and you have 3 or 4 orders of magnitude more RAM than needed. I always think that I'm going to get to teaching the students on my team about efficiency when we get to the point where there would be some benefit to doing so, but things always end up 'good enough'.
-FRC games allow success with limited software functionality. Every year there are robots that have no autonomous program at all and win tournaments. This is silly. The game should start with each robot in a box taped on the floor and you shouldn't get driver control until it leaves the box.
One thing that I must disagree with you about is that restricting changes to code can be rational. Even if your code is correct it does not follow that your system will behave as expected. Minor code changes can and do trigger bugs in other parts of the system. You might now be triggering a different (and buggy) code path in a library you're using. We've all seen compiler bugs before. And there's the famous "download silently failed and left system in an unusable state". When one of these other problems occurs it would be nice to find out why but right before a match is neither the time nor place.
Also, there is some interesting coding going on even if it's not going on a robot. For example, here:
http://www.chiefdelphi.com/forums/sh...hreadid=137451.