We have a lot of community resources around the mechanics of programming, but I wanted to make a thread where people can share resources that help with the less-obvious but more-important aspect of coding: style.
In the real world, code style is everything - most costs associated with code are maintenance rather than initial development, and the biggest impact on how costly it is to maintain code is how appropriately the code is structured and styled.
I’ll start it off with these:
Neither of the above resources are recent, but the thing about code style is that the principles around it really have not changed much even as programming languages themselves have changed greatly. I hope at least some people find these useful.
Please share your code style resources below! Eventually, we might be able to add some of these to an appropriate page on frc-docs.
Team 1672 has a condensed version of the Google’s Java style guide with some additions for FRC-specific “what goes where?” things. I need to update it for the 2023 changes to how we’re handling commands, I’ll post it here once I do.
for the better and so have the editors. Aaaah 1975 - college was a fading memory and I still had (dark) hair and had to wear suits with top and bottom matching. We often had to key punch our own code and very short variable names was the norm. Today we pester the team’s students - use the rename symbol function in VSC immediately to describe better that variable.
One of the most dramatic examples of style matters happened to me about 1967. I was a FORTRAN and PL/I programmer (I’m an engineer) and was pressed into service for a business program which, of course, was strictly COBOL. I wrote the perfect, efficient COBOL program with few commas and more periods like the video. After some weeks of coding I completed it and handed it to the system boss. His jaw dropped and he gasped “You were supposed to write this in COBOL!” I was going back to school the next day and was glad I wasn’t around to have to restyle the program. If an organization wants standards they have to publish them.
I suppose good style is matching the rest of the organization - within limits - for better or for worse.
There are plenty of resources on the Internet about anti-patterns - what not to do and why they are used. A brief one:
