Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add lint for variables whose names contain uppercase characters #12300

Merged
merged 5 commits into from
Mar 5, 2014

Conversation

DaGenix
Copy link

@DaGenix DaGenix commented Feb 15, 2014

I added a new lint for variables whose names contain uppercase characters, since, by convention, variable names should be all lowercase. What motivated me to work on this was when I ran into something like the following:

use std::io::File;
use std::io::IoError;

fn main() {
    let mut f = File::open(&Path::new("/something.txt"));
    let mut buff = [0u8, ..16];
    match f.read(buff) {
        Ok(cnt) => println!("read this many bytes: {}", cnt),
        Err(IoError{ kind: EndOfFile, .. }) => println!("Got end of file: {}", EndOfFile.to_str()),
    }
}

I then got compile errors when I tried to add a wildcard match pattern at the end which I found very confusing since I believed that the 2nd match arm was only matching the EndOfFile condition. The problem is that I hadn't imported io::EndOfFile into the local scope. So, I thought that I was using EndOfFile as a sub-pattern, however, what I was actually doing was creating a new local variable named EndOfFile. This lint makes this error easier to spot by providing a warning that the variable name EndOfFile contains a uppercase characters which provides a nice hint as to why the code isn't doing what is intended.

The lint warns on local bindings as well:

let Hi = 0;

And also struct fields:

struct Something {
    X: uint
}

@DaGenix
Copy link
Author

DaGenix commented Feb 15, 2014

This is an RFC at the moment. Its not currently warning on uppercase variables in function parameters and there may be other missing locations as well. I also haven't completed a make check yet. If this looks like a good addition, I'll add warnings for whatever places I've missed.

@sfackler
Copy link
Member

👍

I think there's an issue filed somewhere to add this lint.

@huonw
Copy link
Member

huonw commented Feb 15, 2014

Maybe we could have it lint for non-snake-case variables? i.e. check for uppercase letters anywhere in the identifier.

@DaGenix
Copy link
Author

DaGenix commented Feb 15, 2014

I think the issue is #3070, although that variable name lint is only one of a few different lints discussed in that issues. So, I don't know if this will close that issue.

@huonw I'll update this PR to warn on any uppercase letter in a variable name.

@DaGenix
Copy link
Author

DaGenix commented Feb 15, 2014

I've updated the PR to warn on any uppercase letter in a variable name and to also warn on function parameters.

@DaGenix
Copy link
Author

DaGenix commented Feb 15, 2014

I realized that I'm not warning on struct fields which it would probably make sense to warn on as well.

@DaGenix
Copy link
Author

DaGenix commented Feb 16, 2014

I just pushed changes to also warn for struct fields with uppercase characters in their names.

@huonw
Copy link
Member

huonw commented Feb 16, 2014

Looks good! Although I think having "uppercase variables" cover uppercase struct fields too is slightly peculiar (rather than being a separate lint... but then having a lint just for that might be even weirder).

@DaGenix
Copy link
Author

DaGenix commented Feb 16, 2014

@huonw I agree its a bit weird. My thinking is that I can't come up with a scenario where someone would want to enable one without the other. I'm happy to split them apart, though.

I also noticed that I'm not current catching variable names in extern functions. I don't know if it makes sense to try to catch those or not.

I also noticed that there were some variables that need renaming that I missed, so, I'm working on getting that all cleaned up

@DaGenix
Copy link
Author

DaGenix commented Feb 16, 2014

I rebased the PR again and now its passing make check NO_BENCH=1, at least on my computer. Unless there are other things that I should do (split it into two lints for variables and struct fields; catch variables in extern functions; or something else), I think this is mergeable if it looks good.

@flaper87
Copy link
Contributor

@DaGenix thanks for this. The PR needs to be rebased again.

@DaGenix
Copy link
Author

DaGenix commented Feb 16, 2014

Cool. I just rebased.

@alexcrichton
Copy link
Member

r=me with a slight adjustment to the error message on struct fields.

@DaGenix
Copy link
Author

DaGenix commented Feb 21, 2014

Rebased to change the warning message on struct fields.

@alexcrichton
Copy link
Member

In light of these errors, perhaps only the first character of variables/structure fields should be linted for now?

@DaGenix
Copy link
Author

DaGenix commented Feb 22, 2014

I'm fine with making this change - this was what the original version of my patch did. However, these all look like windows functions which naturally don't conform to the Rust standards. How about disabling the lint in this module?

@alexcrichton
Copy link
Member

I think this is specific to windows for now, but we should probably start off as conservative before going all the way. While it may be just windows currently, it may be indicative of more unexpected code that purposefully doesn't follow this style.

@DaGenix
Copy link
Author

DaGenix commented Feb 26, 2014

Rebased to only warn if the first character is uppercase. I left in my changes to rename everything I could find that had uppercase characters anywhere in their name since its my understanding that all lowercase variables names are the preferred style.

@DaGenix
Copy link
Author

DaGenix commented Feb 26, 2014

It appears that I accidentally resurrected libstd/to_bytes.rs. I'll rebase this tomorrow to pull that out. Please don't merge until I get a chance to do that. Sorry.

@DaGenix
Copy link
Author

DaGenix commented Feb 27, 2014

Rebased and got rid of to_bytes.rs.

@DaGenix
Copy link
Author

DaGenix commented Feb 27, 2014

bah! Stupid Windows!

@DaGenix
Copy link
Author

DaGenix commented Mar 5, 2014

Rebased against master again. I added a commit to #[allow(uppercase_variables)] in libstd/libc.rs since functions in this module probably don't need to follow Rust variable naming conventions. I wasn't able to get a Windows build to work due to some compiler errors that I don't fully understand. I think this should work on Windows this time, though.

bors added a commit that referenced this pull request Mar 5, 2014
…ichton

I added a new lint for variables whose names contain uppercase characters, since, by convention, variable names should be all lowercase. What motivated me to work on this was when I ran into something like the following:

```rust
use std::io::File;
use std::io::IoError;

fn main() {
    let mut f = File::open(&Path::new("/something.txt"));
    let mut buff = [0u8, ..16];
    match f.read(buff) {
        Ok(cnt) => println!("read this many bytes: {}", cnt),
        Err(IoError{ kind: EndOfFile, .. }) => println!("Got end of file: {}", EndOfFile.to_str()),
    }
}
```

I then got compile errors when I tried to add a wildcard match pattern at the end which I found very confusing since I believed that the 2nd match arm was only matching the EndOfFile condition. The problem is that I hadn't imported io::EndOfFile into the local scope. So, I thought that I was using EndOfFile as a sub-pattern, however, what I was actually doing was creating a new local variable named EndOfFile. This lint makes this error easier to spot by providing a warning that the variable name EndOfFile contains a uppercase characters which provides a nice hint as to why the code isn't doing what is intended.

The lint warns on local bindings as well:

```rust
let Hi = 0;
```

And also struct fields:

```rust
struct Something {
    X: uint
}
```
@bors bors merged commit 258dbd0 into rust-lang:master Mar 5, 2014
@DaGenix DaGenix deleted the uppercase-variable-lint branch March 6, 2014 02:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants