Switch back to soft-tabs #215

Closed
masche842 opened this Issue Mar 31, 2012 · 9 comments

Comments

Projects
None yet
2 participants
Contributor

masche842 commented Mar 31, 2012

Honestly... For sure this is a topic for endless discussion, but it seems that soft-tabs have become standard in the rails world.
Refer to rails_best_practices-gem, github styleguide (https://github.com/styleguide/ruby)...

I really don't want to flame around here, but apart from switching code styles between alchemy and my other projects, personally, I absolutely prefer soft-tabs...

Just a thought & my 0.02$

Owner

tvdeyen commented Mar 31, 2012

I know it really sucks. Softtabs won. Problem is, switching back would cause gazillions of merge conflicts, if we rebase the master from next_stable and it will break the history, because every indentation change is a file change. So every file will be marked as changed.

But I thought about this a lot and I confess: "it was a bad idea" and we really should switch back.

Should be done in one commit. Best with an IDE with indentation refactor capabilities. Does your Rubymine offer this?

@robinboening do you agree?

Contributor

masche842 commented Mar 31, 2012

Me and Ctrl+Q are best friends ;-)

Owner

tvdeyen commented Mar 31, 2012

Lucky, you are not on Windows ;)

What are we doing about Javascript and HTML files?

We should do some researching on how to indent these.

Owner

tvdeyen commented Mar 31, 2012

Ok, some quick research:

Javascript:

Douglas Crockford (Javascript Guru know for his "Javascript: The good parts" Book. Worth reading btw.) sais 4 spaces:
http://javascript.crockford.com/code.html#indentation

4 spaces is also JSLint default:
Quote: "This book, for example, uses four-space indentation, which is also the default in JSLint."

GitHub has CoffeeScript Guideslines, that say 2 spaces. Ok, this is CoffeeScript, not Javascript.

Google is strange: In their Javascript coding guidelines they say 2 spaces when anonymous functions and 4 if a named function. Stupid!

I'll say 4 spaces for Javascript, then

HTML:

Seems to be 2 spaces (http://en.wikipedia.org/wiki/Indent_style) (https://github.com/ginatrapani/ThinkUp/wiki/Code-Style-Guide:-HTML)

CSS:

2 Spaces sais drupal: http://drupal.org/node/302199 and a lot of other resources I found

Conclusion:

Rails handles this very easy: Indent 2 spaces, that's it: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#contributing-to-the-rails-code

So do we follow this easy rule and say:

Indent every code 2 spaces

Do you all agree?

Contributor

masche842 commented Mar 31, 2012

I agree.

What about privat/protected? Rubymine also indents it (see #212, sorry!). Personally I like the unindented version better, but didn't figure out how to change it in Rubymine, yet.

You're also right that it should be done in a single commit. Maybe it's best to rename next_stable to master next time, and inherit a new next_stable from that. The actual master becomes 2.1(?), and when applying fixes one can skip that commit via rebase. Should work.

Owner

tvdeyen commented Apr 1, 2012

I think we should follow widely used standards. The GitHub style guide in example.

https://github.com/styleguide/ruby

I totally agree with them.

I agree.

What about privat/protected? Rubymine also indents it (see #212, sorry!). Personally I like the unindented version better, but didn't figure out yet how to change it in Rubymine.

You're also right that it should be done in a single commit. Maybe it's best to rename next_stable to master next time, and inherit a new next_stable from that. The actual master becomes 2.1(?), and when applying fixes one can skip that commit via rebase. Should work.


Reply to this email directly or view it on GitHub:
magiclabs#215 (comment)

Owner

tvdeyen commented Apr 1, 2012

Oh, you refered the GitHub styleguide :)
So, we agree to follow them then?

The renaming of the master seems to be the best option.

This leads to our former disussion on branch handling. Following all other OSS projects, the master should be the only dev branch. And the fixes for the versions should happen in their version branches.

Maybe this indentazion change is the chance to change our branch handling.

Contributor

masche842 commented Apr 2, 2012

Sounds quite good and reasonable.

I'd say ready when you are. I'll reformat on next_stable and commit that. Then you can tag the current master to a version and rename next_stable to master.

Owner

tvdeyen commented Apr 4, 2012

in current master

tvdeyen closed this Apr 4, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment