I've been working a lot on the code for Citrus Circuits' 2017 robot. I just spent about 3 hours doing code cleanup, which I've found that I actually really enjoy. It's an easy way to make a bunch of low-stress, helpful changes. I've also found a couple cool bash one-liners that helped me out. Here they are:
Find any files with trailing whitespace:
find . -type f -exec egrep -l " +$" {} +
This one is pretty self explanatory - it shows a list of files with any trailing whitespace. This is taken mostly from this stack overflow post, with one small change to make it faster.
Note that it's up to you to actually choose what to do about the whitespace - this just lists all the files.
List include guards:
find . | grep \\.h$ | grep -v "third_party" | xargs head -n 3 | less
This requires a bit more explanation - On 1678, we use the Google C++ Style Guide. Part of the style guide are "include guards". These are #define and #ifndef statements that stop headers from multiple inclusion errors. To make sure each file has a unique include guard, the include guard is defined based on file name. So, for example foo/bar/baz.h would look like this:
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
// code goes here
#endif
This works fine, except when lazy humans get involved. Because typing is a lot of work, and it's really easy to copy paste, and have include guards get out of sync with file names.
The command above will list the filename and first 3 lines of each header file - enough to see if the include guard matches up. It also excludes any directory with third_party in it - that's where we store third party code, and I don't want to have to look through all of that!
I found a ton of issues with this script, from files that were just completely wrong, to multiple files with the same include guard! I can't wait for something like #pragma once to be standard!
Conclusion
Overall, it was interesting to see just how much copy-pasting there was going on. A small issue in one file can quickly become an issue in a ton of files if people use it as a reference implementation.
Another thing that I noticed is the importance of being nitpicky about formatting in the review process - as that's the best chance to actually fix something. After that, it takes way more effort to get things fixed.
I was also surprised at how much fun doing code cleanup was - it feels really nice and is super easy to do!