Re: [rust-dev] Some work on Rust coding standards

2013-04-18 Thread Niko Matsakis
One other thing which I have noticed. The suggested form for a function declaration is difficult to maintain in light of refactorings and in particular search-and-replace commands. That is, if you place each argument on a separate line and line that line up with the opening parenthesis, as

Re: [rust-dev] Some work on Rust coding standards

2013-04-11 Thread Brian Anderson
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.

Re: [rust-dev] Some work on Rust coding standards

2013-04-11 Thread Brian Anderson
On 04/10/2013 05:37 PM, Niko Matsakis wrote: Hi guys, I guess it is time to adopt some consistent standards. Since I wasn't in the room, here are my two cents. # Function docs I prefer putting the

Re: [rust-dev] Some work on Rust coding standards

2013-04-11 Thread Brian Anderson
On 04/10/2013 07:22 PM, Kang Seonghoon wrote: I mostly agree to Niko's comments, but I'd like to point out one issue with function docs. Given the following code: /// This is a doc comment with two paragraphs. /// /// Not actually. pub fn a() { } /** * This is a doc comment with two

Re: [rust-dev] Some work on Rust coding standards

2013-04-11 Thread Brandon Mintern
On Wed, Apr 10, 2013 at 11:20 PM, Brian Anderson bander...@mozilla.comwrote: On 04/10/2013 05:25 PM, Erick Tryzelaar wrote: 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

[rust-dev] Some work on Rust coding standards

2013-04-10 Thread Brian Anderson
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

Re: [rust-dev] Some work on Rust coding standards

2013-04-10 Thread Erick Tryzelaar
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

Re: [rust-dev] Some work on Rust coding standards

2013-04-10 Thread Niko Matsakis
Hi guys, I guess it is time to adopt some consistent standards. Since I wasn't in the room, here are my two cents. # Function docs I prefer putting the function comment *inside* the fn rather than in front. However, I am probably alone on this point, so I'm prepared to lose this fight.

Re: [rust-dev] Some work on Rust coding standards

2013-04-10 Thread Jesse Luehrs
On Wed, Apr 10, 2013 at 05:25:53PM -0700, 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

Re: [rust-dev] Some work on Rust coding standards

2013-04-10 Thread Niko Matsakis
Niko Matsakis wrote: Anyhow, if we are going to place comments in front of the function, I think we should encourage `///` comments in favor of the `/**..*/`. It's been pointed out to me that this is what the style guide already said. Okay then. Niko

Re: [rust-dev] Some work on Rust coding standards

2013-04-10 Thread Kang Seonghoon
I mostly agree to Niko's comments, but I'd like to point out one issue with function docs. Given the following code: /// This is a doc comment with two paragraphs. /// /// Not actually. pub fn a() { } /** * This is a doc comment with two paragraphs. * * Really. */ pub fn b() { }

Re: [rust-dev] Some work on Rust coding standards

2013-04-10 Thread Steve Klabnik
I want my coding standards to be blue! I think this is a damn fine guide. Strong conventions are one of the things I love most about Ruby, so I'd love to see strong conventions in Rust, too, no matter what they are. ___ Rust-dev mailing list