Organized, multiple source code vs everything in one code.

[davidthefat]

What I have noticed is that many teams have just one file source code. Now, I did that last year and I felt very guilty about that. I felt guilty because I usually have multiple source code projects, and those projects are the ones that I really did not care for. I have been taught to use multiple files. What does that tell you about my attitude about the code last year? Now this year we have over 15 files; had we programmed in C++, that would be double that (header and cpp file duos). The code repository is not updated, but you can get the feeling for the mentality here.

Now how many of you guys do what I refer to as "all in one" sources?

[Christopher149]

We currently have a relatively large (~600 lines) main source file, plus another for tracking the scoring peg targets. We may do more breaking up of files, but step one is to make working code, then worry about pretty code.

While we have only two source files, we have at least broken several functions off into their own methods, which provides very useful organization. All-in-one methods (or functions) are far worse than all-in-one source files IMO.

[BigJ]

1675 practices object-oriented design.

I don't think it's about how many files you have, but rather your paradigm. We have 9 source files right now I think.

[basicxman]

Originally Posted by BigJ

1675 practices object-oriented design.

I don't think it's about how many files you have, but rather your paradigm. We have 9 source files right now I think.

* basicxman approves this message

So long as everything is readable, organized and easy to maintain - you are doing something right.

[demosthenes2k8]

We do things COMPLETELY object-oriented. Each task runs as an object, and thus can be enabled or disabled by commenting out their instantiation, and if one crashes, the rest won't.
We have 48 source/header files...

[apalrd]

According to Windows, I have 192 files in my code folder (which includes the robot code and the dashboard, as well as project files and non-VI files).

However, LabVIEW lends itself to having lots of files and I tend to break lots of stuff into re-usable modules that are sometimes shared between multiple sub-systems. According to VI Metrics:

Robot Main has 124 user VI's under it.
Autonomous Thread has 10 user VI's under it
That does not include any of the auto VI's that are called by ref, there are about 15 of them, or the autonomous routines themselves (which are not VI's).

[MagiChau]

My source code files aren't exactly organized the best way. I have a file for the addresses for devices that is called by the main class when constructing the objects. There is one for settings so I could do things like change sensitivity on the acclerometer or change the timeout period for the encoders in one list just for easier way to access than scrolling through the main class.

Regarding actually make stuff do things, as of now I have a class containing code for autonomous, a in-progress one for initiation(teleop, auto, and robot), one for the arm, one for driving, and another for the claw. I probably should have auto/teleop files that calls on code for each component that is then is called to the main file. Didn't really think myself through this season.

[remulasce]

Every mechanism has its own object, from its own class in a separate file. For instance, DriveStation2011.py deals with getting which button from where on the driver station. Everything that needs button presses goes through GetTriangle() or similar, so if the triangle button changes port it's all in one place. For safety, every motor system has its own motor output class, and the system has access to its own sensors in addition to the regular code. That way, we can put limit stops in the actual motor output and so long as we drive motors through the output class, we never have to worry about it anywhere else. We also created DualSpeedControllers, which allow us to treat two motors as one when setting outputs. On top of all that, there is a LineFollowing class for driver aid which is used by both autonomous and teleop to keep track of what state it is in- the driver holds down a button and it follows a line. The LineFollower object keeps track of whether it is drifting off in which direction and also whether we have already found a fork and are refollowing it, etc, exactly the same as in auto, so if we make line following better in auto, it automatically is better in teleop.

[Robototes2412]

can you post a copy of that on the python forum? I need a good excuse to get python on my team's school demo robot (it fires t-shirts, three injuries and no lawsuits yet, lol).

[BugByte]

We separate everything into tasks. When it comes up that something needs to be continually checked or set it becomes a task. These send information and commands to each other with message queues. Our software mentor comes from an old-school embedded programming background. I don't know off the top of my head how many files we have but I think around 10.