Great! We've needed something like this. I worry a little bit about the
function declaration style though. I could see it being difficult to
implement this format in the pretty printer, which would make it hard to
write something like gofix. Here's the longest function declaration I could
find in our codebase, this one in src/librustc/middle/typeck/infer/unify.rs:
fn simple_vars<T:Copy + Eq + InferStr + SimplyUnifiable, V:Copy + Eq +
Vid + ToStr + UnifyVid<Option<T>>>(&mut self, +a_is_expected: bool, +a_id:
V, +b_id: V) -> ures {
Assuming we extended the rule to the typarams, we'd have:
fn simple_vars<T:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr + UnifyVid<Option<T>>>(&mut
self,
+a_is_expected: bool,
+a_id:
V,
+b_id:
V)
-> ures
{
Which in my opinion is hard to read. Then there's the question of what
happens if even after wrapping the line pushes us past the 100 character
limit?
For my bikeshed, I have started using the basic rule that if I can't fit a
statement on one line, I wrap and indent 4 spaces after a '<', '(', or '{':
fn simple_vars<
T:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr + UnifyVid<Option<T>>
>(
&mut self,
+a_is_expected: bool,
+a_id: V,
+b_id: V
) -> ures {
Another option is to do what Go does, and say there's no limit in the line
length, but if the user wants to wrap, just add a tab to the start of the
next line. So it could look something like this
fn simple_vars<
T:Copy + Eq + InferStr + SimplyUnifiable,
V:Copy + Eq + Vid + ToStr + UnifyVid<Option<T>>>(&mut self,
+a_is_expected: bool, +a_id: V, +b_id: V)
-> ures {
It's a little ugly, but it's consistent, and really easy to implement with
a pretty printer. Here are the Go rules:
http://golang.org/doc/effective_go.html#formatting
I personally don't care what style we use, I just want to make sure we
choose a style that's easy to automate so we can move on with our lives.
On Wed, Apr 10, 2013 at 3:57 PM, Brian Anderson <bander...@mozilla.com>wrote:
> There have been a few mentions recently about writing up the Rust coding
> standards. Several of us sat in a room and tried to identify and agree on
> some that we thought were important. I've pasted the resulting notes into
> the wiki:
>
> https://github.com/mozilla/**rust/wiki/Note-style-guide<https://github.com/mozilla/rust/wiki/Note-style-guide>
>
> These are very, very rough but cover a number of topics. Comments and
> suggestions are welcome. These need to be cleaned up into readable prose,
> with decent examples, and moved from the 'Notes' section of the wiki to the
> 'Docs' section where users will find them. Help is definitely appreciated.
>
> -Brian
> ______________________________**_________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
