Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So, I am getting into Ruby. I'm learning it everyday. And just like Spanish. I am getting able to read it, but not write it.
I am doing "Ruby the Hard Way" and I understand WHY things work, but the more I move through it the more I realize that I could not mimic the code if someone just came up to me and said "I need you to do so and so in Ruby."
I know that it is going to depend largely on what the task is, is how my code will be set up. But are there any tips and/or tricks for Ruby. (i.e. "Always write your variables first or strings before arrays" or something like that.
I'm unclear on when to write which lines of code or WHY something has to be below another block of code. I am aware of the nebulous nature of this question, but I'm looking for a bit of more broad rules for Ruby.
I think the WHY in your question has to do with learning the concepts, but not really applying them in a way that's meaningful to you.
I'd recommend finding a task you can accomplish with Ruby. Eg: write to a file, get content out of a webpage, get the date/time in a specific country, whatever. Start small, but challenge yourself. Look at StackOverflow ruby tag, or Github to see what other people are doing with Ruby.
That will get you thinking about the problem you're solving, and not the code alone; which is what programming is all about.
Then come back here and ask about the specifics you're struggling with.
Small disclaimer: yes, all of the above is my opinion; and as others have commented, this question is too broad.
The question is really too broad. I'll suppose that you know of another language already. If you are looking for code convention, look at the Ruby Style Guide. Taking courses at Code School could get you an idea of the good practice (and make you learn useful frameworks like Rails. Reading "The Ruby Way" can give you a feeling of the "pulse" of the language. Building the blog application used by many Rails book could also help.
Finally, checkout sample Rails or Ruby projects from GitHub.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In furthering my study of Ruby, I've noticed that some methods really seem to give power to the language, while others are just syntactic sugar.
Examples of sugar: .split, .strip, i.e. any methods that just make doing a menial task with a data structure easier.
Examples of power methods: call, send, responds_to?, method_missing, etc.
It seems like if you understand those "power methods" you really know the language.
Curious about three things:
Has anyone every made such a distinction, be it in a book/blog post etc?
Do you personally make such a distinction?
If you feel what I'm saying is correct, what "power methods" should I know and use better?
Thanks (hope this question doesn't get closed!)
These aren't really "power methods" but are just another tool in the toolbox that is the Ruby library.
Methods like call and send are for low-level operations, bypassing the usual Ruby semantic layer. responds_to? is often used when writing generic code that uses duck typing, and method_missing is a way of writing code that responds to a variety of methods in a dynamic way. This is how Rails ActiveRecord handles methods calls like find_by_name_or_phone automatically.
Methods like split, strip and chomp are simply data transformation methods. Their primary function is to convert one thing into another, optionally in-place.
I don't think there's a distinction between any of these methods, they're all quite useful, but they do have their particular uses. As far as Ruby is concerned, though, all methods are equal, there's no hierarchy or inherent importance to them.
Some methods you will use very infrequently, so you're less likely to ever have need for them unless you've done a lot of Ruby.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What do you think fellow programmers about using short functions vs using inline code?
Example with function:
//Check if all keys from $keys exist in $array
function functionName(array $array, array $keys) {
return array_diff($keys, array_keys($array));
}
functionName($mas,$keys);
vs. using just the code:
array_diff($keys, array_keys($mas));
I think that in your example, it's superfluous. There's no need to create an extra function call and add bytes to the filesize without good reason.
Also, the inline array_diff($keys, array_keys($mas)); is a lot easier to debug for fellow programmers, than looking through your code to find out exactly what functionName() does and where it is located.
It depends on what functionName actually is.
If you're using customerDetailsAreValid throughout your code and you suddenly have to add validation of $array['email'], you're going to be grateful for the separation of intent and implementation.
If on the other hand you're wrapping array_diff in the function diffArray there isn't much point.
I think clarity is a prime concern when writing logic you hope will be around for any amount of time.
In general, I abhor inline functions. I think they are lazy, promote spaghetti code, and in general exude a complete lack of concern for style/readability/clarity on the part of the developer.
Filesize - I find this argument very arbitrary. The js files are transmitted once and then cahced. In many cases, you find descriptive names, etc, (hopefully comments) that all add to file size. If size is very important , use a file minimizer that makes a file as tiny as possible.
Looking for a function? How about trying to figure out exactly what is going on in a voluminous docReady. CTL-F usually invokes a find facility.
I will grant that there can be simple cases where an inline function detracts little from the readability of the code. However, the inline approach will never be MORE CLEAR than the alternate separation of reference and implementation.
my two cents
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I suspect this question has been asked before, but it's not easy to Google for.
I am a fairly new coder and I see a lot of code, in a lot of different languages, with comments beginning "TODO".
Questions:
Is there a practical reason why people write TODO in all these different languages, or is it merely a convention?
If the latter, where did the convention come from?
I can see why it's useful to be able to grep for TODO, I'm just curious about the history behind it.
Programming is a world-wide activity; conventions to help smooth the process of working with people who are not native speakers of each other's languages are worth their weight in gold. TODO, XXX and FIXME are often highlighted by IDEs, which provides an excellent incentive to stick with these options.
XXX suggests a danger or hazard that maintenance programmers must be aware of;
FIXME insinuates that something is wrong with some implentation which needs to be changes;
TODO explains shortcomings that would be nice to address.
TODO means "to do". Something that someone will need to do. Just guessing, but could this guess be wrong?
Just a quick follow up to the original answer:
This feature is mainly a reference and you'll find it in Frameworks if there are items that aren't detrimental to the code still running, but that the developers would like to address.
The nice thing about modern IDE's, for example I use JetBrains PHPStorm, they actually highlifht TODOs and place them into a Toolbar for your entire project so you can see all the TODOs for all your files differentiated by their directory and file name.
Anyway, just thought this may add further light as to why you may see it throughout code.
In addition to the comments about grepping, editor/IDE identification etc. I would think that a big reason as to why TODO became the standard, instead of say todo or ToDo, is simply that TODO is a big todo.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'd like to write a code beautifier and i thought of using Ruby to do it. Could someone show me a place to get started? I've seen a lot of code beautifiers online but I've never come across any tutorials on how to write one. Is this a very challenging task for someone who's never undertaken any projects such as writing a compiler, parser, etc. before?
(Is there another langauge which would be more well suited for this kind of task, excluding C/C++?)
Python has an interesting feature - it exposes its own parser to scripts. There are examples that use the AST - abstract syntax tree - and do the pretty printing.
I'm not aware that Ruby exposes its own parser to its scripts in such a way, but there are parsers for Ruby written in Ruby here.
Well... I think the initial steps are what you'd do for any project.
Write a list of requirements.
Describe a user interface to your program, that you like and won't prevent you meeting those requirements.
Now you can write down more of a "code" design, and pick the language that would be easiest for you to meet that design.
Here's some requirements off the top of my head:
Supports code beautifying of these languages: Ruby, Python, Perl
Output code behaves identically to input
Output has consistent use of tabs/spaces
Output has consistent function naming convention
Output has consistent variable naming convention
Output has matching braces and indentation
Make as many as you want, it's your program. ;p I was kidding about the Perl, but I think every language you support is going to add a more work.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I use ruby infrequently - usually it adds up to writing a script once in two months or more. I do most of my programming with C++, which is very different from ruby.
with such wide gaps between my brushes with ruby I keep forgetting basic aspects of the language (like parsing a text file and other simple stuff).
I would like to do a daily drill of the basic stuff and I was wondering if there is some site I can subscribe to and will send me the Ruby question of the day or something similar.
anyone knows of such a site / Internet service?
It's not daily, but you might be interested in Ruby Quiz.
You might also subscribe to ruby-talk and look over the posts there each day.
Check out Jim Weirich's ruby koans. It's a set of ruby scripts organized by topic that guides you through the different parts of the language by unit testing your knowledge.
def method_with_block
result = yield
result
end
def test_methods_can_take_blocks
yielded_result = method_with_block { 1 + 2 }
assert_equal __, yielded_result
end
The game is to go through these and fill in the __ blanks. Running rake will check your answers.
What about a general problem site like Project Euler( http://projecteuler.net/ ) or the ACM programming competition problem sets ( http://www.inf.bme.hu/contest/tasks/ ) and just restrict yourself to using ruby?
A more arduous (but awesome) task is the google code jam. Just assign yourself one of the problems, and set a time per week to put an hour into it. Quit while you are still working. That way, you hunger for more, and think about it in the interim time.
http://code.google.com/codejam
TL;DR: Find a large task, that is interesting. Work on it in bite-size pieces, leaving yourself hungry for more.