Ruby - simple question about Return in a method to display a string

[destrekor]

So I'm using codecademy to start learning Ruby.

The instructions for this short exercise:
"Define two methods in the editor:

1. A greeter method that takes a single string parameter, name, and returns a string greeting that person. (Make sure to use return and don't use print or puts.)

2. A by_three? method that takes a single integer parameter, number, and returns true if that number is evenly divisible by three and false if not."

Note the greeter method instructions to return a string greeting.

I've tried a few different things and the code simulator does not agree with me, saying "it looks like your greeter method prints to the console instead of using return."

How do I display a string that isn't displayed in the console? That's what it appears to be saying. Return a string, but don't dare display the string? Because see below, I didn't use print or puts.

def greeter(name)
    return "Hi, #{name}!"
end

I tried the below, also didn't work:

def greeter(name)
    var = "Hi, #{name}!"
    return var
end

As well as the below:

def greeter(name)
    return "Hi, " + name
end

And a few variations of the above.

Looking up online, this simple thing should work. But, hell, now the last two aren't even displaying that string in the console. Yet the simulator is yelling at me that the method prints to the console instead of using return. lol

Is this just a simulator running afoul of itself, as opposed to an actual violation of the intended code?

edit: but the below allows me to proceed, stating I finished the section:

def greeter(name)
    return
end

Which seems to not accomplish the original intent of the instructions.

 

[Crusty]

All of your methods looks OK to me.

You could try using format strings as another alternative to see if it is just their simulator

def greeter(name)
    "Hi, %s" % [name]
end

Note that you do not need the the actual return keyword in any of your methods. The result of the last statement executed in a ruby block is always returned to the caller regardless of using the return keyword.

 

[destrekor]

All of your methods looks OK to me.

You could try using format strings as another alternative to see if it is just their simulator

def greeter(name)
    "Hi, %s" % [name]
end

Note that you do not need the the actual return keyword in any of your methods. The result of the last statement executed in a ruby block is always returned to the caller regardless of using the return keyword.

I'll go back to that section in a little while and see if the simulator approves of your suggestion.
From what I had read and gathered, it definitely seemed the actual return statement was unnecessary, but it's at the point in the instruction that there are still things being done in a certain way to help you see how everything really works, versus showing the most efficient means of coding. I suspect that will come in the later stages of the course.

 

[Spungo]

Note that you do not need the the actual return keyword in any of your methods. The result of the last statement executed in a ruby block is always returned to the caller regardless of using the return keyword.

Please don't do that. The last thing we need is more cryptic looking scripts. Also, please use reasonable variable and function names. "trngl" is not a good name for a triangle. Is there some kind of mental illness that makes people pick terrible names for things? The people who name a string "x" are probably the same people who name their kid Sunshine or DaShiqua. It takes more time to type "trngl" than it does to type "triangle" because one is a word the other is nonsense.

 

[destrekor]

Please don't do that. The last thing we need is more cryptic looking scripts. Also, please use reasonable variable and function names. "trngl" is not a good name for a triangle. Is there some kind of mental illness that makes people pick terrible names for things? The people who name a string "x" are probably the same people who name their kid Sunshine or DaShiqua. It takes more time to type "trngl" than it does to type "triangle" because one is a word the other is nonsense.

While I am no regular coder, I do get what you are saying. At the same time, I also get that people come from all walks of life and many bring their own crazy methodologies to the work they do. It doesn't matter what kind of work, it could be factory work, it could be financial records keeping, everyone has their own means to achieve organization. What works for them may or may not work for others. It takes a lot more foresight, reasoning, logical, and empathetic skills to understand and appreciate how to create a system of any kind that may be of valuable use to any successors.

It's actually rather difficult to understand that. Appreciate those that do, because those are people who likely see many things in a different light... possibly in the same way you do, but in a different way than most of the population.

 

[brianmanahan]

Is there some kind of mental illness that makes people pick terrible names for things?

yes, it is called hungarian notation :awe:

 

[brianmanahan]

i only drop returns in inline closures

 

[purbeast0]

not having return statements in groovy is a very common practice and one of the "groovyisms" that people are supposed to use to be groovy like.

as for variable names, i think a lot of the "var x" stuff stems from what you learn in school. another thing that is taught in school that is bad is that you should use boatloads of comments. in reality, the goal of coding is to make your code as human readable as possible WITHOUT comments. leave the comments for things such as explaining the business rules or WHY things are doing what they are doing. if you have a function called getHeight, there is absolutely no reason to add a comment to that function saying "this function gets height". well yeah, obviously. same thing goes for variables. if you have var height, you don't need a comment saying "this is the height". but if you had var x, and that was the height, then i'd also argue to NOT use a comment and simply change the variable name.

 

[Ken g6]

Is there some kind of mental illness that makes people pick terrible names for things?

I dunno, but I have that too. In school I was criticized for naming a variable that was the "number I was checking" num_chkn. I still don't see the problem with that.

It helps people like me to use single-variable names for loop iterators. I was taught to use i, j, k, etc.

Edit: But I don't know where this came from because the OP's variable and function names look very reasonable to me.

 

[purbeast0]

I dunno, but I have that too. In school I was criticized for naming a variable that was the "number I was checking" num_chkn. I still don't see the problem with that.

It helps people like me to use single-variable names for loop iterators. I was taught to use i, j, k, etc.

Edit: But I don't know where this came from because the OP's variable and function names look very reasonable to me.

why wouldn't you just add the extra letters to make it say number_checking?

i'm assuming that most programmers are competent typers, so it can't be that it saves time really. long term benefit is easier to read code.

there are some people here who write "svc" instead of "service". i can't stand it and just think it's lazy programming.

probably saved about .1 of a second typing svc over service.

 

[brianmanahan]

I dunno, but I have that too. In school I was criticized for naming a variable that was the "number I was checking" num_chkn. I still don't see the problem with that.

it could just as well have been "number of chickens"

 

[destrekor]

I dunno, but I have that too. In school I was criticized for naming a variable that was the "number I was checking" num_chkn. I still don't see the problem with that.

It helps people like me to use single-variable names for loop iterators. I was taught to use i, j, k, etc.

Edit: But I don't know where this came from because the OP's variable and function names look very reasonable to me.

As for my variable names, I used "var" as a fill in here, it wasn't used in code, just to demonstrate the flow.

Everything else is what codecademy dictates. For courses to proceed, things have to be named what they tell you, which is partly how it checks your work.

 

[destrekor]

not having return statements in groovy is a very common practice and one of the "groovyisms" that people are supposed to use to be groovy like.

as for variable names, i think a lot of the "var x" stuff stems from what you learn in school. another thing that is taught in school that is bad is that you should use boatloads of comments. in reality, the goal of coding is to make your code as human readable as possible WITHOUT comments. leave the comments for things such as explaining the business rules or WHY things are doing what they are doing. if you have a function called getHeight, there is absolutely no reason to add a comment to that function saying "this function gets height". well yeah, obviously. same thing goes for variables. if you have var height, you don't need a comment saying "this is the height". but if you had var x, and that was the height, then i'd also argue to NOT use a comment and simply change the variable name.

I'm no proficient programmer, not yet, but I find this is how I would approach it. Comments are only to be used to explain that which is not otherwise inherently obvious, or to explain why something is done a certain way that may otherwise look wrong or inefficient.

 

[brianmanahan]

I'm no proficient programmer, not yet, but I find this is how I would approach it. Comments are only to be used to explain that which is not otherwise inherently obvious, or to explain why something is done a certain way that may otherwise look wrong or inefficient.

:thumbsup:

 

[Childs]

I dunno, but I have that too. In school I was criticized for naming a variable that was the "number I was checking" num_chkn. I still don't see the problem with that.

It helps people like me to use single-variable names for loop iterators. I was taught to use i, j, k, etc.

Edit: But I don't know where this came from because the OP's variable and function names look very reasonable to me.

When I took a C and Fortran in college all variables were reduced down to the minimum. This style of naming things was prevalent in most of the multi user operating systems as well with the names of commands. Maybe at the time it had to do with conserving memory. Part of it is its just quicker to type. I dunno, I didnt pay much attention in those days.

 

[Ken g6]

why wouldn't you just add the extra letters to make it say number_checking?

i'm assuming that most programmers are competent typers, so it can't be that it saves time really. long term benefit is easier to read code.

there are some people here who write "svc" instead of "service". i can't stand it and just think it's lazy programming.

probably saved about .1 of a second typing svc over service.

At the time (some 20 years ago) I was typing on an editor without autocomplete, on a screen that was maybe 80 columns wide at most. As the iterator in a for loop, "number_checking" would take more than half the screen!

Nowadays it would fit fine and I could just type num[Ctrl-N][Ctrl-N] for either form. Old habits, I guess. :\

 

[Crusty]

Please don't do that. The last thing we need is more cryptic looking scripts. Also, please use reasonable variable and function names. "trngl" is not a good name for a triangle. Is there some kind of mental illness that makes people pick terrible names for things? The people who name a string "x" are probably the same people who name their kid Sunshine or DaShiqua. It takes more time to type "trngl" than it does to type "triangle" because one is a word the other is nonsense.

Honestly, personal preference and your teams coding conventions should dictate what you do. Being cryptic for the sake of not having to type more words is stupid.

My rules are that if a method is less than 5 lines and the only point in the method where something is returned is the last line then I leave it out otherwise return is used everywhere something is returned.

Given the way that we write ruby around here most methods tend to not have a return keyword because they are usually short and only return data at the end.

 

[Spungo]

it could just as well have been "number of chickens"

Ha, that's exactly what I thought when I saw it!

It helps people like me to use single-variable names for loop iterators. I was taught to use i, j, k, etc.

Single letters seem acceptable if it's clear what the letter is for. "Thread t = new Thread()" is fairly common. i for integer makes sense. s for string could make sense. x and y could make sense if they actually represent x and y coordinates. If x represents someone's bank account balance, that makes things difficult to follow.

not having return statements in groovy is a very common practice and one of the "groovyisms" that people are supposed to use to be groovy like.

My concern is that people take things way too far and abuse shortcuts. Perl is a great example of this:

# unreadable perl code

@ARGV = qw(thing1 thing2 thing3);
while (<>) {
   if (/"(.+)".*=.*"(.+)"/) {
      return if ($2 =~ /^error/i) 
      else print;
   }
}

You could be the best Java or C programmer in the world and have no idea what this code does. It uses tons of assumptions that are specific to perl. Even people familiar with perl would need to stop for a minute and work through it. Look at that code for 30 seconds and see if you piece together what it does.

1) "<>" is a shortcut that reads line by line, in order, through the files listed in @ARGV. This isn't bad because it could probably be googled in a minute.
2). Putting <> in a while loop is another shortcut. The loop is true as long as there is a line to read. The line being read is stored in a special variable called $_. Notice that $_ is not shown anywhere in the code.
3). The loop is doing a regex search like "something" = "something", but where is that search happening? What is it reading? It's reading that assumed $_ variable, which is the current line read from <>.
4). After that, it checks the second group "something" for the word "error", case insensitive. What is it trying to return? Does it return true if the pattern match is true? Is it trying to return that $_ assumed variable? Is it returning $2?
5). Else print what? Print false? Print $_? Print $2?

Throwing in an extra few characters would make this thing so much easier to read. I honestly don't know what the above code would do. I think it would return or print the entire line on which the first match happens, including the stuff on that line that didn't match. Let's say that's my desired effect. I want the entire line returned. How much extra work is required to make this thing easier to understand?

# somewhat readable perl code

@ARGV = qw(thing1 thing2 thing3);
while (<>) {
   my $entire_line = $_;
   if ($entire_line =~ /"(.+)".*=.*"(.+)"/) {
      if ($2 =~ /^error/i) 
         return $entire_line;
      else 
         print $entire_line;
   }
}

This is absolutely clear. I want the $entire_line. I don't want $2. I don't want true or false. If I want to know what $entire_line is, I can see that it's defined as $_, which is something that can be googled in a minute. Someone who has never seen perl code before could piece together what this thing does. Even the spacing makes this easier to read. Perl allows really weird syntax so it reads a lot like English. You can write things like this:
if (true) { do_something(); }
but you can also write it like this:
do_something() if (true);
Someone who doesn't know that quirk could easily misreading what "return if (something)" is trying to do. It's not returning the evaluation of the if statement. It's returning $_ if the statement is true.

 

[Crusty]

Ha, that's exactly what I thought when I saw it!


Single letters seem acceptable if it's clear what the letter is for. "Thread t = new Thread()" is fairly common. i for integer makes sense. s for string could make sense. x and y could make sense if they actually represent x and y coordinates. If x represents someone's bank account balance, that makes things difficult to follow.


My concern is that people take things way too far and abuse shortcuts. Perl is a great example of this:

# unreadable perl code

@ARGV = qw(thing1 thing2 thing3);
while (<>) {
   if (/"(.+)".*=.*"(.+)"/) {
      return if ($2 =~ /^error/i) 
      else print;
   }
}

You could be the best Java or C programmer in the world and have no idea what this code does. It uses tons of assumptions that are specific to perl. Even people familiar with perl would need to stop for a minute and work through it. Look at that code for 30 seconds and see if you piece together what it does.

1) "<>" is a shortcut that reads line by line, in order, through the files listed in @ARGV. This isn't bad because it could probably be googled in a minute.
2). Putting <> in a while loop is another shortcut. The loop is true as long as there is a line to read. The line being read is stored in a special variable called $_. Notice that $_ is not shown anywhere in the code.
3). The loop is doing a regex search like "something" = "something", but where is that search happening? What is it reading? It's reading that assumed $_ variable, which is the current line read from <>.
4). After that, it checks the second group "something" for the word "error", case insensitive. What is it trying to return? Does it return true if the pattern match is true? Is it trying to return that $_ assumed variable? Is it returning $2?
5). Else print what? Print false? Print $_? Print $2?

Throwing in an extra few characters would make this thing so much easier to read. I honestly don't know what the above code would do. I think it would return or print the entire line on which the first match happens, including the stuff on that line that didn't match. Let's say that's my desired effect. I want the entire line returned. How much extra work is required to make this thing easier to understand?

# somewhat readable perl code

@ARGV = qw(thing1 thing2 thing3);
while (<>) {
   my $entire_line = $_;
   if ($entire_line =~ /"(.+)".*=.*"(.+)"/) {
      if ($2 =~ /^error/i) 
         return $entire_line;
      else 
         print $entire_line;
   }
}

This is absolutely clear. I want the $entire_line. I don't want $2. I don't want true or false. If I want to know what $entire_line is, I can see that it's defined as $_, which is something that can be googled in a minute. Someone who has never seen perl code before could piece together what this thing does. Even the spacing makes this easier to read. Perl allows really weird syntax so it reads a lot like English. You can write things like this:
if (true) { do_something(); }
but you can also write it like this:
do_something() if (true);
Someone who doesn't know that quirk could easily misreading what "return if (something)" is trying to do. It's not returning the evaluation of the if statement. It's returning $_ if the statement is true.

The reason you are seeing stuff like that is because you're using Perl... it comes with the territory I'm afraid. Granted, You still see stuff like that in other languages, but it is no way as pervasive as it is in perl. For some reason perl programmers think that the more concise and consequently hard to read your code is the better it is.

 

[maddogchen]

sounds like a bug, i've seen a few on sites like those.

 

[Ken g6]

Is there some kind of mental illness that makes people pick terrible names for things?

The reason you are seeing stuff like that is because you're using Perl... it comes with the territory I'm afraid. Granted, You still see stuff like that in other languages, but it is no way as pervasive as it is in perl. For some reason perl programmers think that the more concise and consequently hard to read your code is the better it is.

Oh, maybe that's it. Perl was one of the first languages I learned. Maybe learning Perl gives you a mental illness.

P.S. There should be no "else" in the first Perl example, and braces are required in the if...else in the second.

 

[Spungo]

and braces are required in the if...else in the second.

I had to test this to make sure. You're right that perl does not allow implied braces for if/else statements. C# is the one that allows implied braces. We can add braces to the list of things not to assume.

It seems like a lot of problems can be avoid just by avoiding assumptions.