-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ruby Style Agreement #11
Comments
That works for me. Are we using the TomDoc style to document methods as well? |
Notes on the style guide:
I use |
And I just want to highlight this item on the style list:
I see that many people actually use |
What about this one? http://www.caliban.org/ruby/rubyguide.shtml#style This is the one we're attempting to use internally. |
Works for me Scott. |
Seems to be quite similar to the other one. (The other one seemed to explain thing better IMO.) Works for me. |
I see Jim removes his feature branches after they've been merged. Is this normal to do? How does that affect the commit history? |
Another workflow question: I've just completed the Merge coplanar faces feature - which I commited to a feature branch "feature-merge-faces" and made a Pull request. What do I do if I want to work on some other thing until it's merged? I'd like to fix the path issue and some other small fixes. But how could I commit that? To a new branch based on the one I'd just worked on? Or jump back to the master branch - without the merge option feature - and create a new parallel one? |
http://scottchacon.com/2011/08/31/github-flow.html Read this article from the GitHub people - but still not wiser on how to work on multiple fixes while awaiting a Pull Request. |
Note for cleaning up: Exporter is using quite a few Example: if (foo == 'bar') and (biz == 'baz') and (bim == 'bam') Which is more cleanly written as: (And recommended by all style guides I've seen) if foo == 'bar' && biz == 'baz' && bim == 'bam' |
Yeah, I'm not sure the best way to handle these things. I just merged your first request, and the "new" pull request comes across nicely vs. the "latest & greatest" that is now in the repo. So I think this is a decent way to work. |
So what do I now do with my branches? Delete them, and pull the master branch from this main repo? |
Yeah, I seems silly that you'd have to keep old branches around. I suspect github will preserve all of our history for us. So delete away and let's see what happens. |
So, what is the preferred format for documenting methods? RDoc? YARD? I personally prefer the structured and guided manner YARD document methods. RDoc is too freestyling and hippie-like IMO. |
@jimfoltz : what's your workflow inregard to: #11 (comment) |
My workflow is still evolving. I was trying to use branches to group together smaller, related commits for GitHub pull requests. I am not sure how this is working for others. Maybe since the files here are fairly small, it is easier to just review the entire file rather than review each tiny change. I feel stuck at the moment because I am not sure what will happen with the current pull requests. I am not sure if I should base new changes on my branch which may or may not be accepted, or if I should always go ack to the current sketchup/aster branch and create parallel branches from there. |
What do you do with branches after they are merged with this repo's master? I also feel a bit stuck. You've got some large changes, but I want to wait until it's been reviewed and merged before I continue. The SketchUppers are in Las Vegas I think, at Trimble Dimension event. Once Scott is back from that we can get your branch merged. |
Btw, what timezone are you on Jim..? |
US Eastern. I haven't settled on a branch workflow, because I'm still unsure how best to use them on GitHub. But this page[1] and the next has a good explanation of branches. If you want to be able to easily go back to commit, keep the branch (or tag it.) [1] http://think-like-a-git.net/sections/experimenting-with-git.html |
Hey guys, sorry I disappeared. We've indeed been in Vegas at the Trimble Dimensions conference. I'm reviewing requests now... :) |
Useful and interesting breakdown of some Git concepts: http://think-like-a-git.net/sections/testing-out-merges.html |
Don't think we reached a conclusion regarding what style to follow. Anyone? |
Re: Style Guides (2) Most of the guides are written towards System Ruby scripts where there is no danger of clashing with other coder's scripts. (3) A shebang is not needed in a embedded Ruby code file, but the new magic (4) I hate confusing "always do this, except in these cases", etc. Case in point whitespace. Either you always use it around = and operators, or you don't. The bottom line is Ruby is supposed to be human readable. That means whitespace. Making little exceptions like "not after (" or "not before )" do not make code more readable. It does the opposite. Personally with regard to parenthesis and square brackets (subscripts/indices) whatever makes it more readable. I like to put spaces around the argument, IF the expression is complex, or a constant or long-named variable reference. But if it is a literal number index or a small iterator variable like (5) The doc generator may not belong in a style guide. Every guide specifies some other format. |
We decided on the GitHub Ruby styleguide for the SketchUp GitHub project a good while ago. This issue just wasn't updated. Simply because it's a well known style that most open source involved people is familiar with. And consistency is the biggest value to a style guide. Need to update the README to reflect this. |
I would suggest an agreement on a Ruby style guide to follow. It doesn't really matter which one, just an agreed upon once to make style decisions clear and easy. Because we are developing on github and it looks reasonable may I suggest https://github.com/styleguide/ruby
The text was updated successfully, but these errors were encountered: