Coding style guidelines

Scott Seago sseago at redhat.com
Thu Apr 26 16:19:15 UTC 2012


On 04/26/2012 12:04 PM, 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.
>
You're assuming everyone uses full-screen-width buffers. Unless I'm 
editing a file which has much longer-than-average lines, I always have 
two buffers side-by-side in emacs. Usually this is on my 12" X-series 
laptop screen -- on here with default editor font size, each buffer can 
hold 87 chars before scrolling. That said, I do _not_ favor a strict 80 
col limit (unlike some on the team have expressed a preference for in 
the past). Ruby makes line breaking more difficult than some other 
languages, and I'd rather see an occasional scroll-around than a really 
awkward line break. That said, as stated above, if most of your lines 
are 120 chars long you're doing something wrong and it will be hard for 
me to read on my 87-character-wide buffers.

> 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...."
>
I agree with having a flexible guideline, but again I don't want to see 
most lines >100 chars long (since they'll all scroll for me). In most 
cases, all you have to do is split args across multiple lines, or array 
elements, or whatever -- basically if you hit a point where you have a 
comma and you're at 75 chars or more, continue on the next line. Many of 
our too-long lines can be fixed fairly easily this way. For me, it's 
more obvious when I need to break a line -- when it wraps around in my 
own editor.


>> * 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.
>
> -- Matt




More information about the aeolus-devel mailing list