Recherche…


Introduction

Bien qu'il n'y ait pas de guide officiel de style Rust, les exemples suivants montrent les conventions adoptées par la plupart des projets Rust. Suivre ces conventions alignera le style de votre projet sur celui de la bibliothèque standard, ce qui facilitera la lecture de la logique dans votre code.

Remarques

Les directives officielles de style Rust étaient disponibles dans le dépôt Rust rust-lang/rust Rust sur GitHub, mais elles ont été supprimées récemment, en attendant la migration vers le dépôt rust-lang-nursery/fmt-rfcs . Tant que de nouvelles directives ne sont pas publiées, vous devriez essayer de suivre les instructions du référentiel rust-lang .

Vous pouvez utiliser rustfmt et clippy pour vérifier automatiquement votre code pour les problèmes de style et le formater correctement. Ces outils peuvent être installés avec Cargo, comme ceci:

cargo install clippy
cargo install rustfmt

Pour les exécuter, vous utilisez:

cargo clippy
cargo fmt

Espace blanc

Longueur de la ligne

// Lines should never exceed 100 characters. 
// Instead, just wrap on to the next line.
let bad_example = "So this sort of code should never really happen, because it's really hard to fit on the screen!";

Échancrure

// You should always use 4 spaces for indentation. 
// Tabs are discouraged - if you can, set your editor to convert
// a tab into 4 spaces.
let x = vec![1, 3, 5, 6, 7, 9];
for item in x {
    if x / 2 == 3 {
        println!("{}", x);
    }
}

Trailing Whitespace

Les espaces à la fin des fichiers ou des lignes doivent être supprimés.

Opérateurs binaires

// For clarity, always add a space when using binary operators, e.g.
// +, -, =, *
let bad=3+4;
let good = 3 + 4;

Cela s'applique également aux attributs, par exemple:

// Good:
#[deprecated = "Don't use my class - use Bar instead!"]

// Bad:
#[deprecated="This is broken"]

Les points-virgules

// There is no space between the end of a statement
// and a semicolon.

let bad = Some("don't do this!") ;
let good: Option<&str> = None;

Alignement des champs de structure

// Struct fields should **not** be aligned using spaces, like this:
pub struct Wrong {
    pub x  : i32,
    pub foo: i64 
}

// Instead, just leave 1 space after the colon and write the type, like this:
pub struct Right {
    pub x: i32,
    pub foo: i64
}

Signatures de fonction

// Long function signatures should be wrapped and aligned so that
// the starting parameter of each line is aligned
fn foo(example_item: Bar, another_long_example: Baz, 
       yet_another_parameter: Quux) 
       -> ReallyLongReturnItem {
    // Be careful to indent the inside block correctly!
}

Bretelles

// The starting brace should always be on the same line as its parent.
// The ending brace should be on its own line.
fn bad()
{
    println!("This is incorrect.");
}

struct Good {
    example: i32
}

struct AlsoBad {
    example: i32 }

Créer des caisses

Préludes et réexportations

// To reduce the amount of imports that users need, you should
// re-export important structs and traits.
pub use foo::Client;
pub use bar::Server;

Parfois, les caisses utilisent un module de prelude pour contenir des structures importantes, tout comme std::io::prelude . Habituellement, ceux-ci sont importés avec use std::io::prelude::*;

Importations

Vous devez commander vos importations et vos déclarations comme suit:

  • déclarations de extern crate
  • use importations
    • Les importations externes provenant d'autres caisses devraient être prioritaires
  • Re-exportations ( pub use )

Appellation

Structs

// Structs use UpperCamelCase.
pub struct Snafucator {
    
}

mod snafucators {
    // Try to avoid 'stuttering' by repeating 
    // the module name in the struct name.

    // Bad:
    pub struct OrderedSnafucator {
    
    }
      
    // Good:
    pub struct Ordered {
        
    }
}

Traits

// Traits use the same naming principles as 
// structs (UpperCamelCase).
trait Read {
    fn read_to_snafucator(&self) -> Result<(), Error>;
}

Caisses et Modules

// Modules and crates should both use snake_case.
// Crates should try to use single words if possible.
extern crate foo;
mod bar_baz {
    mod quux {

    }
}

Variables statiques et constantes

// Statics and constants use SCREAMING_SNAKE_CASE.
const NAME: &'static str = "SCREAMING_SNAKE_CASE";

Enums

// Enum types and their variants **both** use UpperCamelCase.
pub enum Option<T> {
   Some(T),
   None
}

Fonctions et méthodes

// Functions and methods use snake_case
fn snake_cased_function() {

}

Liaisons variables

// Regular variables also use snake_case
let foo_bar = "snafu";

Des vies

// Lifetimes should consist of a single lower case letter. By 
// convention, you should start at 'a, then 'b, etc.

// Good:
struct Foobar<'a> {
    x: &'a str
}

// Bad:
struct Bazquux<'stringlife> {
    my_str: &'stringlife str
}

Acronymes

Les noms de variables contenant des acronymes, tels que TCP doivent être libellés comme suit:

  • Pour les noms UpperCamelCase , la première lettre doit être en majuscule (par exemple, TcpClient )
  • Pour les noms snake_case , il ne devrait pas y avoir de majuscule (par exemple, tcp_client )
  • Pour les noms SCREAMING_SNAKE_CASE , l'acronyme doit être complètement mis en majuscule (par exemple, TCP_CLIENT )

Les types

Type Annotations

// There should be one space after the colon of the type
// annotation. This rule applies in variable declarations,
// struct fields, functions and methods.

// GOOD:
let mut buffer: String = String::new();
// BAD:
let mut buffer:String = String::new();
let mut buffer : String = String::new();

Les références

// The ampersand (&) of a reference should be 'touching'
// the type it refers to.

// GOOD:
let x: &str = "Hello, world.";
// BAD:
fn fooify(x: & str) {
    println!("{}", x);
}

// Mutable references should be formatted like so:
fn bar(buf: &mut String) {

}


Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow