On 26/04/12 12:36 -0400, Scott Seago wrote:
On 04/26/2012 12:15 PM, Hugh O. Brock wrote:
>On Thu, Apr 26, 2012 at 12:04:06PM -0400, Matt Wagner wrote:
>>On Thu, Apr 26, 2012 at 05:25:04PM +0200, Maros Zatko wrote:
>>>Hi everybody,
>>>
>>>I'd love to ask you if we have some coding style guidelines.
>>>If we don't I'd like to propose creating such thing and start to
>>>enforce it in a review process.
>>To my knowledge, all we really have is a notion of what others have done
>>in the past. But I think it would be a good idea to start to write those
>>things up on a wiki page.
>>
>>>some of the guidelines ideas are:
>>>* 2 spaces over tabs
>>>* fuzzy (i.e. non-strict limit) for 80 chars per line (and yes - 120
>>>chars are way too much)
>>I'm not sure I completely agree with this one. There is certainly some
>>point at which lines are too long, but I'm not sure 80 characters is it.
>>It feels like a carryover from VT100 days, and I can view considerably
>>more than 80 characters on even my 13" laptop at home.
>>
>>What I'd rather see is a guideline like, "Try to keep your lines to 120
>>characters at most. If you cannot easily refactor code to use shorter
>>lines, here is the recommended best practice of spanning multiple
>>lines...."
>>
>>>* using instance variables only when you *really* need it
>>>* 'do...end' and curly braces conventions (?)
>>>* CamelCaseOnlyForClassNames
>>Some of these are standard Ruby conventions, e.g., using curly braces
>>only for one-liners, vs. do..end for multi-line blocks, or
>>CamelCaseOnlyForClassNames. I seem to recall having read a really great
>>overview of many common Ruby conventions in the past, but, of course, I
>>cannot find it now.
>>
>>Personally, I'd rather our list was more a set of "Best Practices"
or
>>"Preferred Conventions" to help us be more consistent, versus a set of
>>mandatory rules. Some larger projects (which shall remain nameless) seem
>>to irritate a lot of people by having rigid requirements that presumably
>>started off as well-intentioned guidelines to help keep things
>>consistent/structured, but turned into a set of hurdles that don't
>>always have any benefit.
>>
>>Do you want to take a stab at throwing some of these up the wiki, and
>>others can add more (or object to some of them)? I have a few more I can
>>think of adding.
>Jim Meyering actually did a lot of work on coding standards at one
>point, including the infamous no-trailing-whitespace rule.
>
>We had also had a hard 80-character line limit at one point, which I
>wholeheartedly support... but seeing as how I don't submit very many
>patches I don't have a leg to stand on.
>
I already commented on the char limit in another message, but since
you mention the hard limit here, I'll comment further. Those who
oppose the limit point out that "screens are wider these days," but
they forget entirely that many of us (myself and probably also jim and
clalance -- who both advocated for the hard limit of 80 chars) will
use two side-by-side buffers to see more code on the screen at once.
In my case, I get 87 chars per buffer before wraparound with two
side-by-side buffers in emacs on my 12" X-series screen, using default
font sizing.
However, I'd rather advocate for an 80 char "soft" limit. i.e. Limit
to 80 chars, unless doing so would be really awkward. Ruby doesn't
always make line breaks easy to do, and sometimes the hoops you have
to jump through to avoid wraparound results in code that is _less_
readable than if it simply wrapped around in an 80-char-wide buffer,
as long as the number of wrapped-around lines is relatively small.
+1 to this. I totally agree with the sentiment that 'screens are
wider these days' is not a relevant metric. Anyone who uses emacs,
vim, screen, tmux- or heck, even an ide- may frequently have 2 files
open side by side, thus effectively cutting screen with in half (yes,
I added IDE to the list so martyn would feel included). Granted that
almost any modern editor can wrap lies as you mention in the emacs
example, but I don't feel that is a strong enough argument to advocate
long lines lengths other than in rare situations where they cannot be
avoided (and imo, these situations should be _exceedingly_ rare).
Aside from this one point, I think in general, we should follow ruby
community standards, as this is a ruby project. I have not read
Michal's link yet, but given how respected github is, I suspect their
guidelines a probably pretty close to those of the overall ruby
community.
-j
>However in all of this discussion I would urge the community to
>consult the grizzled veterans among you (Jim is a good example) --
>they've hashed through these issues many many times before and can
>tell you in precise detail *why* a particular standard is a good idea
>or not.
>
>--Hugh
>