Swerve

Reuseable code for the swerve drivebase chassis

---

This is Team 1280's swerve and limelight codebase. The codebase is written with a high level of precision and focus on simplicity. This is a template that future EECS leads are encouraged to fork for future swerve robots or use as an example of what not to do. Hopefully by the time future EECS members use this, there will be water games.

Hardware Debugging

Before amending this repo, please refer to the basics of the human nature (Ezekiel 18:25-32, "Basic Nature of Man (BNOM), Busboom"). There may (will) be many issues regarding hardware, such as faulty electrical connections, lack of attention and bad design choices among the CAD and mechanical teams, funding problems as a result of poor business decisions, or media team public relation failures. These encountered issues will be documented within the Errors & Issues file, and they are not our problem. If your code doesn't work, simply delegate blame as necessary to the mechanical, electrical, and business subteams. We encourage amendments to Errors & Issues when problems arise.

Amending and Editing the Repo

Thorough testing is necessary for the perfection of Swerve. Before amending and rm -rfing the entire codebase, you are to open a new branch in this repository to work on new features so the main branch remains stable. After finishing a feature branch, consult the current EECS or programming leads in order to create a Pull Request (PR). A PR is a request for a code review on your new branch. A bureaucratic committee, also known as an Arch Linux users convention, will then decide whether to merge your PR into main, following resolution of all merge conflicts.

There is a failsafe mechanism contingent upon a rookie member eviscerating the entirety of the codebase. Only in exceptionally rare circumstances should you have to directly force a push into the main branch. If there were a regretful push, we encourage using git reset --hard <previous commit>. Otherwise this would happen:

Style

From the linux kernel style guide (with amendments):

C Java is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C Java programmers do not use cute names like ThisVariableIsATemporaryCounter. A C based programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand.

HOWEVER, while mixed-case names are frowned upon, descriptive names for global (constants) variables are a must. To call a global function foo is a shooting offense.

GLOBAL Constant variables (to be used only if you really need them) need to have descriptive names, as do global functions. If you have a function that counts the number of objects, you should call that countObjects() or similar, you should not call it cntobj() OR countTheActiveObjects(). Basically invoking this function on an object should be similar to natural language, sans the articles and useless English bits.

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called i. Calling it loop_counter is non-productive, if there is no chance of it being mis-understood. Similarly, tmp can be just about any type of variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions).

However, do not be a fascist concerning the use of git. There is only one person merging branches at a time anyway, and the maintainers of this repository promise to remain anarchist-adjacent.

Directory

• Robot
  • Code
    • Warren's code (!!!)
    • Good code

---

AI generated code is strictly prohibited on this repository.