Fix Clang-Tidy violations?

[mfdorst]

I'm personally a big fan of linter tools, and since this is an LLVM extension it seems like we should be using Clang-Tidy.

I just wanted to check before I submit a pull request with a whole bunch of little code changes to fix clang-tidy issues.

Some examples of clang-tidy changes would be:

std::map<string, string>::const_iterator it = settings.find(name);

ClangTidy: Use auto when declaring iterators

auto it = settings.find(name);

---

while (!file.fail() && name.size() && name[0] == '#') {

ClangTidy: The 'empty' method should be used to check for emptiness instead of 'size'

while (!file.fail() && name.empty() && name[0] == '#') {

[kerbowa]

Sure!

[mfdorst]

Cool! What about unused code? We have a lot of unused code and I'm not sure if it's because we will use it, or if it's just old dead code that hasn't been removed.

[kerbowa]

There is definitely a lot of refactoring/cleanup that could be done, and I don't think anyone would object to these sort of things.

I did a clang-format passover in the past and in some of my private branches I'd removed some code that is no longer relevant if we are not doing scheduling at the SD level. It's fine to remove dead code; be careful though.

The older portions of the codebase also need to be updated in terms of the data structures used to rely on stl and LLVM more. Variables need to be renamed and follow LLVM style and CamelCase: https://llvm.org/docs/CodingStandards.html

The significant overhead from loading config files and the way we handle compiler options needs to be improved since it has a big impact on compile time.

There are lots of these tasks to be done to improve the overall code quality which is quite poor at the moment, but these types of tasks are not likely to be things that are interesting to Dr. Shobaki.

I don't have time to work on/contribute to this project at the moment, but feel free to do pretty much anything.

[mfdorst]

I see a lot of variables named likeThis_ with an underscore at the end. I noticed in one class that all the protected variables ended in underscores while the public ones did not. Is that a convention we should continue to uphold?

[kerbowa]

The convention used is that class members end in an underscore. LLVM's coding style has CamelCase for both local and class members. We should also rename variables in cases where the abbreviation (wrong spelling) makes it hard to read.

[mfdorst]

I've been reading up on LLVM's code style conventions, and I see that variables are supposed to be capitalized camel case, but I don't see anything about underscores. To be clear, is underscores thing just our own coding convention? And does it go on all members or just private/protected ones?

[kerbowa]

The underscores should be removed. The only time I see them in llvm is for things like. Class(Foo Bar_) : Bar(Bar_)

Renaming would be good to. I.e. vctr_ -> Vector, bitCnt_ -> BitCount

[mfdorst]

That is on my list of things to do. Right now we're supposed to solve knapsack for Prof. Shobaki, so I'll get back to this whenever I get that done.

[Quincunx271]

To be clear on the state of this: #77 fixed the majority of these cases. What's left to fix is the casing of our variable names.

[Quincunx271]

#176 captures the remaining point.