Document constants/

[ZWORX52]

Lowest priority. All files are actually (name)Constants.java, except for Constants.java which is just that

• [x] Angle
• [x] CANdle
• [x] Climber
• [x] Constants.java
• [x] Drivetrain
• [x] Feeder
• [x] Intake
• [x] Limelight
• [x] Shooter
• [ ] Tuner

[ZWORX52]

@JacobyIA Use javadoc please.

[ZWORX52]

I've overridden your changes on Feeder and Intake constants -- please see my version. Javadoc (/**, *, and */) is the standard and should be used over //

[JacobyIA]

Yep, hadn't realized javadoc worked on static values, a whoopsie on my part. I can fix ShooterConstants, so long as you aren't already wip there

[JacobyIA]

One thing, it would seem that you didn't fully document as the docs only apply to some of the fields, I will complete.

[ZWORX52]

Mmmhhh some of them don't need comments. The philosophy should be that code never needs comments, and these unimportant bits of documentation are just these types of useless documentation.

However I lost that fight :c

So we're writing useless comments now. Do as you wish

[JacobyIA]

The problem is that JavaDocs is only meant to be used for legitimate documentation. If we are simply including inline info about values, as we have in the past, then it was not truly necessary. The problem comes now that we have decided to use JavaDocs for individual values, meaning that if we wish to maintain parity (as I believe we should and hope you would too), we should document all values.

[ZWORX52]

We could just not document these. Oh whatever.

[minglethepringle]

@ZWORX52 agreed that you should strive to write code that explains itself and doesn't need documentation

[ZWORX52]

:o https://www.youtube.com/watch?v=Bf7vDBBOBUA

[JacobyIA]

CodeAesthetic, my old friend. I am of the opinion that it doesn't matter either way, but since we are on this path we should see it through. Plus, it may help any new software members (because there will totally be a ton of them) with better understanding the robot's logic.

[ZWORX52]

It'll be better to make effective large-scale presentations.

[JacobyIA]

Oh no, totally. But again, its better to cover all bases in case we don't do that, because plans are never guarantees.

[JacobyIA]

Plus, its not like I have much else to work on right now. I need to be coding during CS, and writing docs counts.

[ZWORX52]

Fair enough.

... Unsure if this counts as "coding", but it's a project nonetheless: use obsidian to make a flow-chart (use their "canvas") out of md-files. Help. OK if you don't want to do this, or if I should, but it could definitely help. I'll start it.

[ZWORX52]

e1e3f89

[JacobyIA]

Hell yes. I love Obsidian, I had never considered integrating it into the codebase though. It seems a good idea, we should just be cautious to not let it overcomplicate things, as we are already amidst other projects with more to come.

[ZWORX52]

Mmm yes.. I added .obsidian to .gitignore; probably should remove that. Just a thought. It's quite good with git. https://www.youtube.com/watch?v=WgV6M1LyfNY

On 5/17/24 9:28 AM, Jacoby @.***> wrote:

Hell yes. I love Obsidian, I had never considered integrating it into the codebase though. It seems a good idea, we should just be cautious to not let it overcomplicate things, as we are already amidst other projects with more to come.

— Reply to this email directly, view it on GitHub https://github.com/team5735/FRC-2024/issues/23#issuecomment-2117609269, or unsubscribe https://github.com/notifications/unsubscribe-auth/APZGPAGHDEYHGBMY3IQJXFDZCYAWJAVCNFSM6AAAAABHUIAUBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGYYDSMRWHE. You are receiving this because you were mentioned.Message ID: @.***>

[JacobyIA]

Yeah probably. As an aside, No Boilerplate is one of my favorite inspirations for coding.

[JacobyIA]

Also we should probably move this to another issue.