On 04/10/2013 05:25 PM, Erick Tryzelaar wrote:
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 <http://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 {
This indentation looks pretty crazy here because I see a non-monospace
font, but your point about type parameters is well-taken. We were not
considering them.
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 {
I like this style as well. It wasn't so popular in a straw vote.
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
<mailto: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
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 <mailto:Rust-dev@mozilla.org>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
